Logical network domains stretched between public and private datacenters

ABSTRACT

Some embodiments provide a method for a network controller. The method configures a first data compute node (DCN), operating within a public first datacenter that includes forwarding elements to which the network controller does not have access, to operate as a gateway forwarding element between (i) other DCNs in the first datacenter on which forwarding elements are configured by the network controller and (ii) forwarding elements in a second datacenter. The method configures the forwarding elements executing on the other DCNs in the public datacenter to implement a logical switch to which the other DCNs attach. The method configures the forwarding elements in the second datacenter to implement the logical switch. DCNs in the second datacenter also attach to the same logical switch.

BACKGROUND

A common datacenter setup includes numerous servers that host virtualmachines or other data compute nodes, with forwarding elements (e.g.,software virtual switches) in the virtualization software of the serverhandling packet forwarding and network security for these data computenodes. In a private datacenter (e.g., an enterprise network), technologyexists that allows the owner of the datacenter to control thehypervisors of the host servers and thereby implement their own securityand packet forwarding rules.

Public datacenters provide companies with the ability to expand or movetheir networks out of their own private datacenters, thereby reducingthe cost and other burdens of the physical servers and the regularupkeep required for them. However, public datacenters have their ownowners that control the virtualization software, and may not have asrobust or transparent security capabilities. As such, some companies arehesitant to move their networks into these public datacenters because ofthe inability to exercise direct security control.

BRIEF SUMMARY

Some embodiments of the invention provide a network management andcontrol system with the ability to manage a logical network that spansacross (i) a private datacenter, in which the system can access andcontrol the forwarding elements and (ii) one or more public multi-tenantdatacenters in which the system does not have access to the forwardingelements. In the private datacenter of some embodiments, the networkmanagement and control system (referred as network control systemherein) manages software forwarding elements that execute in thevirtualization software (e.g., hypervisor) of the host machines, andtherefore can implement the administrator's desired network forwardingand security policies. However, in the public datacenter, the networkcontrol system does not have access to the virtualization software, andtherefore may not be able to implement the same networking policies toworkloads operating in the public datacenter.

Some embodiments use a hierarchical network control system to expand theprivate datacenter management and control into the public datacenter.Specifically, some embodiments operate network controllers and managedforwarding elements inside virtual machines (VMs) or other data computenodes (DCNs) operating in the public datacenter, in order to enforcenetwork security and forwarding rules for packets sent to and from thoseDCNs. In some embodiments, the public datacenter(s) provide tenants withone or more isolated sets of resources (i.e., data compute nodes) overwhich the tenant has control, also referred to as virtual private clouds(VPCs). With some cloud providers, the tenant can define a virtualnetwork with network subnets and routing tables, and/or place their DCNsinto security groups defined by the public cloud provider.

To implement the hierarchical network control system, some embodimentsimplement a first level of network controller (referred to as a gatewaycontroller) in a first DCN in each VPC (or a set of DCNs asactive-standby gateway controllers in each VPC). These gateway DCNs alsooperate a gateway datapath in some embodiments, for communication withthe logical network in other VPCs of the same datacenters or in otherdatacenters (either the private datacenter or another publicdatacenter), and with external networks. Within each workload DCN (i.e.,a DCN executing a workload application, such as a web server,application server, database server, etc.), a managed forwarding element(MFE) is inserted into the datapath between the workload application andthe network interface of the DCN. In addition, a local control agentexecutes on each of the workload DCNs, to configure their respectiveMFEs.

A central control plane cluster operating in the private datacenter (orin a separate VPC) distributes configuration rules to local controllersoperating on host machines in the private datacenter based on the spanof the rule (i.e., the MFEs that will need to implement the rule basedon the type of rule and the logical ports to which the rule applies).For distributing these rules to the control system operating in thepublic datacenter VPC, the central controller views all of the logicalports that correspond to DCNs in the VPC as connected to a MFEcontrolled by the gateway controller. As such, all of these rules arepushed to the gateway controller by the central controller.

The gateway controller then does its own separate span calculation, inorder to identify the MFEs in the VPC that require each rule receivedfrom the central controller, and distributes these rules to the localcontrol agents operating to control the MFEs. The local control agents,upon receiving the rules, convert the rules into a format specific tothe MFEs operating on their DCN. For instance, some embodiments useflow-based MFEs such as Open vSwitch (OVS) instances executing on theDCNs in the public datacenter VPC, in which case the local controlagents convert the rules into flow entries and/or other configurationdata for the OVS instance.

The gateway controller, in some embodiments, is also responsible formanaging the overlay tunnels within its VPC. Because the centralcontroller views the entire VPC as being a single MFE, it onlyconfigures a tunnel endpoint for the gateway controller node (i.e., adatapath configured on the gateway DCN). However, for communicationbetween the workload applications within the VPC (and between theworkload applications and the gateway datapath), the central controllerdoes not configure the overlay. As such, the gateway controller sets upthe tunnels (e.g., STT, GENEVE, etc. tunnels) between these VMs, byconfiguring the MAC to virtual tunnel endpoint (VTEP) IP bindings foreach MFE. This information is also passed to the various local controlagents on the workload DCNs, so that each MFE has the ability to tunnelpackets to the other MFEs in the same VPC.

As mentioned, the gateway DCN includes a gateway controller and adatapath. The datapath, in some embodiments, operates as a gateway toconnect the workloads in its VPC to (i) workloads connected to thelogical network that operate in other VPCs and other datacenters and(ii) the external network. In some embodiments, the gateway DCN includesthree network interfaces: an uplink interface that receives packets fromand sends packets to the external networks (via a cloud providerinternet gateway), a VTEP interface with an address on the local VPCsubnet, and a control interface used exclusively for control traffic. Inaddition to the datapath and the gateway controller, some embodimentsmay include a distributed network encryption (DNE) manager for handlingencryption keys used for securing traffic by the MFEs within the VPC(including, in some cases, the gateway datapath), a DHCP module forhandling DHCP within the VPC, and a public cloud manager (PCM) thatenables the management plane and gateway controller to interact with thepublic cloud management system.

An additional feature of the gateway DCN is the ability to handlecompromised DCNs within its VPCs. For example, if a hacker gains accessto a DCN executing a MFE, the hacker could (i) uninstall the localcontrol agent and/or MFE, (ii) create a new interface that does not sendtraffic through the MFE, (iii) disconnect the existing interface fromthe MFE, or (iv) directly reprogram the MFE by disconnecting the MFEfrom the local control agent. If the interfaces are edited, or thecontrol agent is disconnected from the MFE, then the agent will detectthe change and notify the gateway controller of the problem. If theagent itself is removed, then the gateway controller will detect theloss of connectivity to the agent and identify that the DCN iscompromised. In either case, the gateway controller manages the threatby ensuring that the DCNs will be unable to send or receive traffic.

The hierarchical network control system enables the implementation of alogical network that stretches from the private datacenter into thepublic datacenter. In different embodiments, different logicaltopologies may be implemented in different ways across datacenters. Forexample, some embodiments constrain the DCNs attached to a given logicalswitch to a single VPC in the private datacenter, or multiple VPCswithin the same datacenter that are peered in order to operate similarlyto a single VPC (although this logical switch may be logically connectedthrough a logical router to a logical switch implemented in another VPCor another datacenter). In other embodiments, a single logical switchmay have DCNs in multiple non-peered VPCs of the same public datacenter,multiple VPCs of multiple public datacenters, and/or both public andprivate datacenters.

While the above describes the extension of the control plane into a VPCand the gateway controller that enables this extension, these variouscomponents within the VPC must be initially configured and broughton-board with the management plane and central control plane in someembodiments. In some embodiments, the initial setup of the network andcontrol system in the public cloud is managed by an operations manager(also referred to as a life cycle manager, or LCM). The networkadministrator interacts with this LCM (e.g., via a user interface) whichuses the public cloud credentials of the network administrator to accessthe LCM and initially configure the various VMs in the VPC.

The LCM identifies each VPC in which the administrator wants toimplement the logical network, and automatically instantiates a gatewayDCN (or an active-standby set of gateway DCNs) in each of these VPCs. Insome embodiments, the gateway DCN is provided as a prepackaged instanceformatted for the particular public cloud provider. In addition, the LCMof some embodiments receives information from the administrator as towhich DCNs existing in the VPC should be managed by the network controlsystem, and provides logical switch and security group informationregarding these DCNs to the management plane.

As part of the initial configuration, the gateway controller needs to becertified with the management plane (and verify the management planeapplication as valid), and similarly with the central controllerapplication(s) with which the gateway controller interacts. In addition,each local control agent operating in one of the workload DCNs verifiesitself with the gateway controller, in a hierarchical manner similar tothat of the configuration rule distribution.

As mentioned, the MFEs of some embodiments are flow-based MFEs such asOVS instances. In different embodiments, these OVS instances may besetup in either a non-overlay mode, a first overlay mode that usesseparate internal and external IP addresses, or a second overlay modethat uses the same IP address for its VTEP and the internal workloadapplication. In all three cases, two bridges are set up in the OVSinstance, but in three different manners for the three options. Theworkload application connects to an internal port on an integrationbridge, which performs network security and/or logical forwardingoperations. A physical interface (PIF) bridge connects to the virtualnetwork interface controller (VNIC) of the DCN on which the MFEoperates.

In the non-overlay mode of some embodiments, the IP address of theworkload application is the same as the IP address of the VM networkinterface (assigned by the cloud provider) that faces the cloud providernetwork (referred to herein as the underlay network). In this case, theMFE does not perform any packet forwarding, and instead is configured toperform micro-segmentation and/or network security processing such asdistributed firewall rule processing. This network security processingis performed by the integration bridge, and packets are by default sentto the PIF bridge via a patch port between the two bridges.

In other embodiments, the MFEs are configured such that the internalinterface to which the workload application connects (e.g., on theintegration bridge) has a different IP address than the outward-facinginterface (on the PIF bridge). In this case, the MFE (e.g., theintegration bridge) performs packet forwarding according to the logicalnetwork configuration in addition to any network security or otherprocessing. Packets are sent by the workload application using a firstinternal IP address that maps to the logical switch port to which theworkload DCN connects, then encapsulated using the IP address assignedby the cloud provider (i.e., that of the VNIC). The integration bridgeperforms the encapsulation in some embodiments and sends the packetthrough a second network stack to a VTEP on the PIF bridge.

Finally, the network administrator may want to keep the same IPaddresses for workloads that are already in existence, but make use ofthe logical network for packet processing, tunneling, etc. In this thirdcase, the MFE is configured in a separate namespace of the workload VMfrom the application. This enables the workload application to connectto an interface of the namespace having its existing IP address, andthen use a veth pair to connect this interface to the MFE in itsseparate namespace, which uses the same IP address for its VTEP. The useof separate namespaces for the workload application and for the MFEallows separate network stacks to use the same IP address, in someembodiments.

The above-described use of overlay encapsulation primarily to east-westtraffic between the workload DCNs in a public cloud VPC. However, manylogical networks include workloads that should be accessible by externalclients. For instance, a typical three-tier (web servers, app servers,database servers) setup will require at least the web servers to be ableto connect with clients via the Internet. Because the VPC subnets aretypically private IP addresses that may be re-used by numerous VPCs ofdifferent tenants (and re-used at various different datacenters),network address translation (NAT) is generally used to modify the sourceIP address of outgoing packets (and, correspondingly, the destination IPaddress of incoming packets) from the internally-used private IP addressto a public IP address.

Furthermore, when the logical network is implemented at least partiallyin a public datacenter, the actual translation to a public IP addressmight need to be performed by the cloud provider's internet gateway,rather than by any of the MFEs managed by the network control system.However, because the cloud provider will not have assigned the internalIP addresses used in the overlay mode, packets should not be sent to theprovider's gateway using these internal addresses. Instead, the MFEs ofsome embodiments perform their own NAT to translate the internal IPaddresses to addresses registered with the cloud provider.

Different embodiments may implement this address translation in adifferent manner. Some embodiments apply NAT as part of the gatewaydatapath. In this case, north-bound packets are tunneled from the sourceMFE to the gateway, where the IP address is translated in a consistentmanner to a secondary IP address. Some embodiments use a NAT table thatmaps each internal workload IP address to a secondary IP addressregistered with the cloud provider. All of these secondary IP addressesare then associated with the gateway's northbound interface, and thecloud provider's gateway performs translation from these secondary IPaddresses to public IP addresses. In the centralized case, other networkservices may also be applied at the gateway, such as service chaining(sending packets out to third-party service appliances for variousmiddlebox processing), intrusion detection, north-south firewall, VPN,audit logging, etc. In addition, when the gateway performs NAT, any loadbalancing will need to be performed in the gateway as well (the cloudprovider may not be able to perform load balancing in this case becauseas far as the provider's gateway is concerned, all traffic is sent tothe gateway interface).

Other embodiments perform the first level of NAT in a distributedmanner, in the MFE operating on the source DCN (the destination DCN forincoming traffic). In this case, for outgoing packets, the MFE at thesource DCN performs address translation and sends the translated packetdirectly to the cloud provider gateway, bypassing the gateway. As such,the source MFE differentiates between overlay traffic that itencapsulates using its VTEP IP and north-south traffic that it sendsunencapsulated onto the cloud provider underlay network (in someembodiments, using the same IP address as the VTEP). Because thistraffic (in both directions) does not pass through the gateway, anyservice chaining, intrusion detection, north-south firewall rules,logging, etc. is performed at the MFE operating on the workload VM.

For load balancing, distributed internal NAT allows the use of existingload balancing features of the cloud provider. Instead of using multiplepublic IP addresses, a single public IP address (or only a small numberof addresses) can be used, and all incoming connections are sent to thisaddress. The internet gateway (or a special load balancing appliance) ofthe cloud provider performs load balancing to distribute theseconnections across different workload VMs (which still need to performtheir own internal NAT) in a balanced manner.

For packets sent between logical network workloads, some embodimentsenable the use of distributed network encryption (DNE) managed by thenetwork control system. In some embodiments, DNE for the DCNs in thepublic datacenter is only available between DCNs operating within thesame VPC or within peered VPCs, while in other embodiments DNE isavailable between any two DCNs attached to logical ports of the logicalnetwork (including between a workload DCN and a gateway).

Distributed network encryption, in some embodiments, allows the networkcontrol system administrator to set encryption and/or integrity rulesfor packets. These rules define (i) what packets the rule will beapplied to and (ii) the encryption and/or integrity requirements forthose packets. Some embodiments define the packets to which a ruleapplies in term of the source and destination of the packet. Thesesource and destination endpoints may be defined based on IP addresses oraddress ranges, MAC addresses, logical switch ports, virtual interfaces,L4 port numbers and ranges, etc., including combinations thereof.

Each rule, in addition, specifies whether packets meeting the source anddestination characteristics require encryption (along withauthentication), only authentication, or plaintext (which may be used asa setting in order to allow broadcast packets. Encryption requires theuse of a key to encrypt a portion or all of a packet (e.g., the entireinner packet, only the L4 and up headers, the entire inner and outpacket for a tunneled packet, etc.), while authentication does notencrypt the packet but uses the key to create authentication data thatthe destination can use to verify that the packet was not tampered withduring transmission.

To have the MFEs in a network implement the DNE rules, the networkcontrol system needs to distribute the keys to the MFEs in a securemanner. Some embodiments use a DNE module in the gateway DCN in order tocommunicate with the DNE aspects of the network control system anddistribute keys to the MFEs operating in the workload DCNs in its VPC.For each rule requiring the use of an encryption key, the DNE modulereceives a ticket for a key from the central controller. The DNE moduleuses the ticket to request the key from a secure key management storage,which verifies that the ticket is authentic and returns a master key.The DNE module of some embodiments calculates session keys for eachconnection specified by the rule (e.g., a single connection between twoworkloads in the VPC, multiple connections within the VPC, connectionsbetween workloads and the gateway, etc.) and distributes these keys tothe appropriate local control agents.

The preceding Summary is intended to serve as a brief introduction tosome embodiments of the invention. It is not meant to be an introductionor overview of all of the inventive subject matter disclosed in thisdocument. The Detailed Description that follows and the Drawings thatare referred to in the Detailed Description will further describe theembodiments described in the Summary as well as other embodiments.Accordingly, to understand all the embodiments described by thisdocument, a full review of the Summary, Detailed Description and theDrawings is needed. Moreover, the claimed subject matters are not to belimited by the illustrative details in the Summary, Detailed Descriptionand the Drawing, but rather are to be defined by the appended claims,because the claimed subject matters can be embodied in other specificforms without departing from the spirit of the subject matters.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features of the invention are set forth in the appendedclaims. However, for purposes of explanation, several embodiments of theinvention are set forth in the following figures.

FIG. 1 conceptually illustrates a hierarchical network control system ofsome embodiments that manages forwarding elements in both a privatedatacenter and a public datacenter.

FIG. 2 conceptually illustrates the flow of control data through thenetwork control system of FIG. 1.

FIG. 3 conceptually illustrates a process of some embodiments todistribute configuration data to managed forwarding elements located inboth private and public datacenters.

FIG. 4 conceptually illustrates a process of some embodiments fordistributing logical network configuration data to the MFEs within aVPC.

FIG. 5 conceptually illustrates an example of a network control systemfor a logical network implemented entirely within a public datacenter.

FIG. 6 conceptually illustrates a network control system of someembodiments that expands a logical network into multiple publicdatacenters.

FIG. 7 conceptually illustrates the architecture of a gateway VM of someembodiments.

FIG. 8 conceptually illustrates a process of some embodiments toinitially extend a network control system managing a private datacenterinto one or more VPCs of a public datacenter.

FIG. 9 conceptually illustrates a process of some embodiments forcertifying a gateway with the management and control planes.

FIG. 10 conceptually illustrates a process of some embodiments performedby a local control agent operating on a DCN in a public cloud VPC tocertify itself with the gateway controller for that VPC.

FIG. 11 conceptually illustrates a logical topology of some embodiments,as an administrator might input the topology into the management plane.

FIG. 12 illustrates an example of four VMs attached to a logical switch,as implemented within a single VPC of a single public cloud provider.

FIG. 13 illustrates an example in which a logical switch is stretchedacross two separate VPCs within a single datacenter (i.e., of the samecloud provider).

FIG. 14 illustrates an example in which a logical switch is stretchedacross VPCs located in datacenters of two completely different cloudproviders.

FIG. 15 conceptually illustrates a VM with a managed forwarding elementconfigured in non-overlay mode.

FIG. 16 illustrates an example of packet processing through a VPC byMFEs operating in non-overlay mode, showing a first workload applicationsending a packet to another workload application on the same VPC.

FIG. 17 conceptually illustrates a VM with a managed forwarding elementconfigured in overlay mode, with distinct IP addresses for (i) theinternal port used by the application and (ii) the VTEP thatencapsulates packets to be sent to other VMs on the same VPC.

FIG. 18 illustrates an example of packet processing through a VPC byMFEs operating in overlay mode, specifically showing a first workloadapplication sending a packet to another workload application on the sameVPC.

FIG. 19 illustrates an example of packet processing through a VPC byMFEs in overlay mode for a packet sent to a logical network destinationoutside the VPC.

FIG. 20 conceptually illustrates a VM with a managed forwarding elementconfigured in overlay mode, but using the same IP address for theinternal port.

FIG. 21 conceptually illustrates an example of packet processing througha cloud provider network for a northbound packet sent from a workloadapplication to a destination outside the logical network.

FIG. 22 illustrates the processing within the public cloud gateway whenan incoming packet is sent from an external source to one of the publicIP addresses associated with the tenant's VPC.

FIG. 23 illustrates the packet processing through the cloud providernetwork of FIG. 21 for a packet sent from a different workloadapplication on the same VPC as the workload application in FIG. 21.

FIG. 24 conceptually illustrates a VM with a managed forwarding elementconfigured in overlay mode with distinct IP address, that also performsNAT for north-south traffic.

FIGS. 25 and 26 illustrate examples of packet processing through a cloudprovider network for northbound and southbound in the distributed NATsetup.

FIG. 27 conceptually illustrates a process performed by a MFE on aworkload VM to process an outgoing packet, when the MFE operates inoverlay mode and is configured to perform distributed NAT.

FIG. 28 illustrates the use of load balancing in a public cloud gatewayalong with distributed NAT by MFEs operating in workload VMs.

FIG. 29 conceptually illustrates a DNE rule and key distribution systemof some embodiments, as well as the flow of data to implement a DNE ruleon a MFE in the public datacenter.

FIG. 30 conceptually illustrates a process of some embodiments formanaging DNE keys in the gateway of a public datacenter VPC.

FIGS. 31 and 32 illustrate examples of a gateway controller identifyingcompromised VMs in its public datacenter VPC.

FIG. 33 conceptually illustrates an electronic system with which someembodiments of the invention are implemented.

DETAILED DESCRIPTION OF THE INVENTION

In the following detailed description of the invention, numerousdetails, examples, and embodiments of the invention are set forth anddescribed. However, it should be understood that the invention is notlimited to the embodiments set forth and that the invention may bepracticed without some of the specific details and examples discussed.

Some embodiments of the invention provide a network management andcontrol system with the ability to manage a logical network that spansacross (i) a private datacenter, in which the system can access andcontrol the forwarding elements and (ii) one or more public multi-tenantdatacenters in which the system does not have access to the forwardingelements. In the private datacenter of some embodiments, the networkmanagement and control system (referred as network control systemherein) manages software forwarding elements that execute in thevirtualization software (e.g., hypervisor) of the host machines, andtherefore can implement the administrator's desired network forwardingand security policies. However, in the public datacenter, the networkcontrol system does not have access to the virtualization software, andtherefore may not be able to implement the same networking policies toworkloads operating in the public datacenter.

Some embodiments use a hierarchical network control system to expand theprivate datacenter management and control into the public datacenter.Specifically, some embodiments operate network controllers and managedforwarding elements inside virtual machines (VMs) or other data computenodes (DCNs) operating in the public datacenter, in order to enforcenetwork security and forwarding rules for packets sent to and from thoseDCNs. In some embodiments, the public datacenter(s) provide tenants withone or more isolated sets of resources (i.e., data compute nodes) overwhich the tenant has control, also referred to as virtual private clouds(VPCs). With some cloud providers, the tenant can define a virtualnetwork with network subnets and routing tables, and/or place their DCNsinto security groups defined by the public cloud provider.

To implement the hierarchical network control system, some embodimentsimplement a first level of network controller (referred to as a gatewaycontroller) in a first DCN in each VPC (or a set of DCNs asactive-standby gateway controllers in each VPC). These gateway DCNs alsooperate a gateway datapath in some embodiments, for communication withthe logical network in other VPCs of the same datacenters or in otherdatacenters (either the private datacenter or another publicdatacenter), and with external networks. Within each workload DCN (i.e.,a DCN executing a workload application, such as a web server,application server, database server, etc.), a managed forwarding element(MFE) is inserted into the datapath between the workload application andthe network interface of the DCN. In addition, a local control agentexecutes on each of the workload DCNs, to configure their respectiveMFEs.

A central control plane cluster operating in the private datacenter (orin a separate VPC) distributes configuration rules to local controllersoperating on host machines in the private datacenter based on the spanof the rule (i.e., the MFEs that will need to implement the rule basedon the type of rule and the logical ports to which the rule applies).For distributing these rules to the control system operating in thepublic datacenter VPC, the central controller views all of the logicalports that correspond to DCNs in the VPC as connected to a MFEcontrolled by the gateway controller. As such, all of these rules arepushed to the gateway controller by the central controller.

The gateway controller then does its own separate span calculation, inorder to identify the MFEs in the VPC that require each rule receivedfrom the central controller, and distributes these rules to the localcontrol agents operating to control the MFEs. The local control agents,upon receiving the rules, convert the rules into a format specific tothe MFEs operating on their DCN. For instance, some embodiments useflow-based MFEs such as Open vSwitch (OVS) instances executing on theDCNs in the public datacenter VPC, in which case the local controlagents convert the rules into flow entries and/or other configurationdata for the OVS instance.

The gateway controller, in some embodiments, is also responsible formanaging the overlay tunnels within its VPC. Because the centralcontroller views the entire VPC as being a single MFE, it onlyconfigures a tunnel endpoint for the gateway controller node (i.e., adatapath configured on the gateway DCN. However, for communicationbetween the workload applications within the VPC (and between theworkload applications and the gateway datapath), the central controllerdoes not configure the overlay. As such, the gateway controller sets upthe tunnels (e.g., STT, GENEVE, etc. tunnels) between these VMs, byconfiguring the MAC to virtual tunnel endpoint (VTEP) IP bindings foreach MFE. This information is also passed to the various local controlagents on the workload DCNs, so that each MFE has the ability to tunnelpackets to the other MFEs in the same VPC.

As mentioned, the gateway DCN includes a gateway controller and adatapath. The datapath, in some embodiments, operates as a gateway toconnect the workloads in its VPC to (i) workloads connected to thelogical network that operate in other VPCs and other datacenters and(ii) the external network. In some embodiments, the gateway DCN includesthree network interfaces: an uplink interface that receives packets fromand sends packets to the external networks (via a cloud providerinternet gateway), a VTEP interface with an address on the local VPCsubnet, and a control interface used exclusively for control traffic. Inaddition to the datapath and the gateway controller, some embodimentsmay include a distributed network encryption (DNE) manager for handlingencryption keys used for securing traffic by the MFEs within the VPC(including, in some cases, the gateway datapath), a DHCP module forhandling DHCP within the VPC, and a public cloud manager (PCM) thatenables the management plane and gateway controller to interact with thepublic cloud management system.

An additional feature of the gateway DCN is the ability to handlecompromised DCNs within its VPCs. For example, if a hacker gains accessto a DCN executing a MFE, the hacker could (i) uninstall the localcontrol agent and/or MFE, (ii) create a new interface that does not sendtraffic through the MFE, (iii) disconnect the existing interface fromthe MFE, or (iv) directly reprogram the MFE by disconnecting the MFEfrom the local control agent. If the interfaces are edited, or thecontrol agent is disconnected from the MFE, then the agent will detectthe change and notify the gateway controller of the problem. If theagent itself is removed, then the gateway controller will detect theloss of connectivity to the agent and identify that the DCN iscompromised. In either case, the gateway controller manages the threatby ensuring that the DCNs will be unable to send or receive traffic.

The hierarchical network control system enables the implementation of alogical network that stretches from the private datacenter into thepublic datacenter. In different embodiments, different logicaltopologies may be implemented in different ways across datacenters. Forexample, some embodiments constrain the DCNs attached to a given logicalswitch to a single VPC in the private datacenter, or multiple VPCswithin the same datacenter that are peered in order to operate similarlyto a single VPC (although this logical switch may be logically connectedthrough a logical router to a logical switch implemented in another VPCor another datacenter). In other embodiments, a single logical switchmay have DCNs in multiple non-peered VPCs of the same public datacenter,multiple VPCs of multiple public datacenters, and/or both public andprivate datacenters.

While the above describes the extension of the control plane into a VPCand the gateway controller that enables this extension, these variouscomponents within the VPC must be initially configured and broughton-board with the management plane and central control plane in someembodiments. In some embodiments, the initial setup of the network andcontrol system in the public cloud is managed by an operations manager(also referred to as a life cycle manager, or LCM). The networkadministrator interacts with this LCM (e.g., via a user interface) whichuses the public cloud credentials of the network administrator to accessthe LCM and initially configure the various VMs in the VPC.

The LCM identifies each VPC in which the administrator wants toimplement the logical network, and automatically instantiates a gatewayDCN (or an active-standby set of gateway DCNs) in each of these VPCs. Insome embodiments, the gateway DCN is provided as a prepackaged instanceformatted for the particular public cloud provider. In addition, the LCMof some embodiments receives information from the administrator as towhich DCNs existing in the VPC should be managed by the network controlsystem, and provides logical switch and security group informationregarding these DCNs to the management plane.

As part of the initial configuration, the gateway controller needs to becertified with the management plane (and verify the management planeapplication as valid), and similarly with the central controllerapplication(s) with which the gateway controller interacts. In addition,each local control agent operating in one of the workload DCNs verifiesitself with the gateway controller, in a hierarchical manner similar tothat of the configuration rule distribution.

As mentioned, the MFEs of some embodiments are flow-based MFEs such asOVS instances. In different embodiments, these OVS instances may besetup in either a non-overlay mode, a first overlay mode that usesseparate internal and external IP addresses, or a second overlay modethat uses the same IP address for its VTEP and the internal workloadapplication. In all three cases, two bridges are set up in the OVSinstance, but in three different manners for the three options. Theworkload application connects to an internal port on an integrationbridge, which performs network security and/or logical forwardingoperations. A physical interface (PIF) bridge connects to the virtualnetwork interface controller (VNIC) of the DCN on which the MFEoperates.

In the non-overlay mode of some embodiments, the IP address of theworkload application is the same as the IP address of the VM networkinterface (assigned by the cloud provider) that faces the cloud providernetwork (referred to herein as the underlay network). In this case, theMFE does not perform any packet forwarding, and instead is configured toperform micro-segmentation and/or network security processing such asdistributed firewall rule processing. This network security processingis performed by the integration bridge, and packets are by default sentto the PIF bridge via a patch port between the two bridges.

In other embodiments, the MFEs are configured such that the internalinterface to which the workload application connects (e.g., on theintegration bridge) has a different IP address than the outward-facinginterface (on the PIF bridge). In this case, the MFE (e.g., theintegration bridge) performs packet forwarding according to the logicalnetwork configuration in addition to any network security or otherprocessing. Packets are sent by the workload application using a firstinternal IP address that maps to the logical switch port to which theworkload DCN connects, then encapsulated using the IP address assignedby the cloud provider (i.e., that of the VNIC). The integration bridgeperforms the encapsulation in some embodiments and sends the packetthrough a second network stack to a VTEP on the PIF bridge.

Finally, the network administrator may want to keep the same IPaddresses for workloads that are already in existence, but make use ofthe logical network for packet processing, tunneling, etc. In this thirdcase, the MFE is configured in a separate namespace of the workload VMfrom the application. This enables the workload application to connectto an interface of the namespace having its existing IP address, andthen use a veth pair to connect this interface to the MFE in itsseparate namespace, which uses the same IP address for its VTEP. The useof separate namespaces for the workload application and for the MFEallows separate network stacks to use the same IP address, in someembodiments.

The above-described use of overlay encapsulation primarily to east-westtraffic between the workload DCNs in a public cloud VPC. However, manylogical networks include workloads that should be accessible by externalclients. For instance, a typical three-tier (web servers, app servers,database servers) setup will require at least the web servers to be ableto connect with clients via the Internet. Because the VPC subnets aretypically private IP addresses that may be re-used by numerous VPCs ofdifferent tenants (and re-used at various different datacenters),network address translation (NAT) is generally used to modify the sourceIP address of outgoing packets (and, correspondingly, the destination IPaddress of incoming packets) from the internally-used private IP addressto a public IP address.

Furthermore, when the logical network is implemented at least partiallyin a public datacenter, the actual translation to a public IP addressmight need to be performed by the cloud provider's internet gateway,rather than by any of the MFEs managed by the network control system.However, because the cloud provider will not have assigned the internalIP addresses used in the overlay mode, packets should not be sent to theprovider's gateway using these internal addresses. Instead, the MFEs ofsome embodiments perform their own NAT to translate the internal IPaddresses to addresses registered with the cloud provider.

Different embodiments may implement this address translation in adifferent manner. Some embodiments apply NAT as part of the gatewaydatapath. In this case, north-bound packets are tunneled from the sourceMFE to the gateway, where the IP address is translated in a consistentmanner to a secondary IP address. Some embodiments use a NAT table thatmaps each internal workload IP address to a secondary IP addressregistered with the cloud provider. All of these secondary IP addressesare then associated with the gateway's northbound interface, and thecloud provider's gateway performs translation from these secondary IPaddresses to public IP addresses. In the centralized case, other networkservices may also be applied at the gateway, such as service chaining(sending packets out to third-party service appliances for variousmiddlebox processing), intrusion detection, north-south firewall, VPN,audit logging, etc. In addition, when the gateway performs NAT, any loadbalancing will need to be performed in the gateway as well (the cloudprovider may not be able to perform load balancing in this case becauseas far as the provider's gateway is concerned, all traffic is sent tothe gateway interface).

Other embodiments perform the first level of NAT in a distributedmanner, in the MFE operating on the source DCN (the destination DCN forincoming traffic). In this case, for outgoing packets, the MFE at thesource DCN performs address translation and sends the translated packetdirectly to the cloud provider gateway, bypassing the gateway. As such,the source MFE differentiates between overlay traffic that itencapsulates using its VTEP IP and north-south traffic that it sendsunencapsulated onto the cloud provider underlay network (in someembodiments, using the same IP address as the VTEP). Because thistraffic (in both directions) does not pass through the gateway, anyservice chaining, intrusion detection, north-south firewall rules,logging, etc. is performed at the MFE operating on the workload VM.

For load balancing, distributed internal NAT allows the use of existingload balancing features of the cloud provider. Instead of using multiplepublic IP addresses, a single public IP address (or only a small numberof addresses) can be used, and all incoming connections are sent to thisaddress. The internet gateway (or a special load balancing appliance) ofthe cloud provider performs load balancing to distribute theseconnections across different workload VMs (which still need to performtheir own internal NAT) in a balanced manner.

For packets sent between logical network workloads, some embodimentsenable the use of distributed network encryption (DNE) managed by thenetwork control system. In some embodiments, DNE for the DCNs in thepublic datacenter is only available between DCNs operating within thesame VPC or within peered VPCs, while in other embodiments DNE isavailable between any two DCNs attached to logical ports of the logicalnetwork (including between a workload DCN and a gateway).

Distributed network encryption, in some embodiments, allows the networkcontrol system administrator to set encryption and/or integrity rulesfor packets. These rules define (i) what packets the rule will beapplied to and (ii) the encryption and/or integrity requirements forthose packets. Some embodiments define the packets to which a ruleapplies in term of the source and destination of the packet. Thesesource and destination endpoints may be defined based on IP addresses oraddress ranges, MAC addresses, logical switch ports, virtual interfaces,L4 port numbers and ranges, etc., including combinations thereof.

Each rule, in addition, specifies whether packets meeting the source anddestination characteristics require encryption (along withauthentication), only authentication, or plaintext (which may be used asa setting in order to allow broadcast packets. Encryption requires theuse of a key to encrypt a portion or all of a packet (e.g., the entireinner packet, only the L4 and up headers, the entire inner and outpacket for a tunneled packet, etc.), while authentication does notencrypt the packet but uses the key to create authentication data thatthe destination can use to verify that the packet was not tampered withduring transmission.

To have the MFEs in a network implement the DNE rules, the networkcontrol system needs to distribute the keys to the MFEs in a securemanner. Some embodiments use a DNE module in the gateway DCN in order tocommunicate with the DNE aspects of the network control system anddistribute keys to the MFEs operating in the workload DCNs in its VPC.For each rule requiring the use of an encryption key, the DNE modulereceives a ticket for a key from the central controller. The DNE moduleuses the ticket to request the key from a secure key management storage,which verifies that the ticket is authentic and returns a master key.The DNE module of some embodiments calculates session keys for eachconnection specified by the rule (e.g., a single connection between twoworkloads in the VPC, multiple connections within the VPC, connectionsbetween workloads and the gateway, etc.) and distributes these keys tothe appropriate local control agents.

The above describes the network management and control system of someembodiments. The following sections describe different aspects of theexpansion of the system into public datacenters in greater detail.Section I describes the hierarchical network control system of someembodiments, while Section II describes the architecture of gatewayDCNs. Next, Section III describes the initial configuration of a publiccloud VPC. Section VI then describes different physical implementationsof logical topologies, stretching topologies across multiple VPCs and/ordatacenters. Section V describes different configurations for the MFEsoperating in workload DCNs, while Section VI describes the provision ofNAT and other services in both centralized and distributed manners.Next, Section VII describes the implementation of distributed networkencryption in the public datacenter, while Section VIII describes threatdetection and handling. Finally, Section IX describes an electronicsystem with which some embodiments of the invention are implemented.

I. Hierarchical Network Control System

As mentioned above, some embodiments use a hierarchical network controlsystem to expand the management of a private datacenter into a publicmulti-tenant datacenter (“public cloud”) such as Amazon Web Services,Microsoft Azure, etc. FIG. 1 conceptually illustrates such ahierarchical network control system 100 of some embodiments that managesforwarding elements in both a private datacenter 105 and a publicdatacenter 110. Both of the datacenters 105 and 110 include hostmachines for hosting virtual machines (VMs) or other data compute nodes(DCNs). In the private datacenter 105, the network control system hasthe ability to manage the hypervisors (virtualization software), andtherefore the forwarding elements that are integrated with thosehypervisors. However, in the public datacenter 110, the network controlsystem does not have access to the hypervisors, as these are controlledby the owner of the datacenter.

As shown, the network control system within the private datacenterincludes a management plane/central control plane (MP/CCP) cluster 115and a local controller 120 on each of numerous host machines 125. Thelocal controller 120 exercises direct control over a set of managedforwarding elements (MFEs) 130 on the host machine. As shown, VMs (orother data compute nodes) on the host machine connect to the MFE set 130(e.g., via a virtual network interface controller (VNIC)) in order tosend and receive data traffic. Based on forwarding and configurationdata received via the network control system, the MFE set 130 performsforwarding and network security (e.g., distributed firewall (DFW) rules,access control list (ACL) rules, etc.) operations on the data packetssent to and from these VMs. The MFE set may be a single managedforwarding element (e.g., a single virtual switch that performs L2, L3,and additional processing) in some embodiments, or may be a combinationof various managed forwarding and security elements (e.g., a set offilters, L2 switch(es), L3 router(s), etc. that all operate within thevirtualization software).

As described herein, the MP/CCP cluster 115 includes a management plane(MP) and central control plane (CCP) with distinct features. In somesuch embodiments, the MP and CCP are separate applications that mayoperate on the same or different physical machines. In addition, theMP/CCP cluster 115 of some embodiments may include a single managementplane application with a single central control plane application, acluster of management plane applications with a cluster of centralcontrol plane applications, a single management plane application with acluster of central control plane applications, or vice versa. It shouldbe understood that in other embodiments, the various features of theseapplications could be combined into a single manager or controllerapplication (or cluster of such applications) without departing from theinvention.

In some embodiments, the management plane provides applicationprogramming interfaces (APIs) through which administrators (e.g., via acloud management application) of the private datacenter 105 enterconfiguration data to configure one or more logical networks to beimplemented within the private datacenter 105 and/or one or more publicdatacenter(s). The logical network configuration from the administratormay include a network of logical L2 switches and logical L3 routers(with the logical router possibly including connections to other logicalrouters and/or subnets external to the logical network (e.g., in orderto connect to the Internet)). The logical network configuration data mayalso include network address translation (NAT) rules, load balancingrules, rules for sending packets to third-party services, networksecurity rules (e.g., DFW rules), etc.

The management plane of some embodiments converts the logical networkconfiguration into rules defining logical forwarding elements (e.g.,logical switches and routers), logical ports for the logical forwardingelements, security and encryption rules for the logical ports, etc. Thecentral control plane of some embodiments handles the distribution ofthese rules to the appropriate MFEs. In some embodiments, the centralcontrol plane keeps track of the location in the physical network ofeach logical port, and therefore the first-hop managed forwardingelement for that logical port. Upon receiving a rule for a particularlogical port and/or logical forwarding element, the central controlplane identifies the span for that rule (i.e., the MFEs that need toreceive the rule in order to properly implement the logical network) anddistributes the rule to local controllers 120 that directly interactwith the MFEs 130 on their respective host machines 125. The span for arule regarding a logical port may be just the MFE(s) on the host wherethat logical port exists (i.e., the MFE set on the host machine thathosts the DCN attached to the logical port), or numerous MFEs (e.g.,every MFE on a host machines that hosts a DCN attached to the samelogical network as that logical port).

The above describes the network control system of some embodiments for adatacenter in which the network control system has access to thevirtualization software of the host machines, and thus can control thenetworking for numerous DCNs on a single host machine (by controllingthe MFEs in the virtualization software). However, when expanding alogical network into the public cloud, the network control system nolonger has access to the virtualization software, as the public cloudprovider's network management system manages the host machines. Thenetworking and security provided by the public cloud provider may or maynot be adequate for the prospective tenant, but in any case is not underthe direct control of that tenant and may not mesh adequately with theiron-premises network (in the private datacenter).

Thus, FIG. 1 illustrates a technique of some embodiments to expand thenetwork control system 100 into the public datacenter 110 withoutrequiring control over the virtualization software of the host machinesin the public datacenter. This figure illustrates a virtual privatecloud (VPC) 135 created in the public datacenter 110 for the owner ofthe private datacenter 105 (referred to herein as the tenant of thepublic datacenter). The virtual private cloud 135 (or similarconstructs, depending on the public cloud provider) is a logicallyisolated set of resources of the public datacenter 110 over which thetenant has control. With some cloud providers, the tenant can define avirtual network with network subnets and routing tables and/or placetheir VMs into security groups (that are defined by the public cloudprovider). However, the tenant does not have direct control over theforwarding elements in the cloud provider, and may not have the abilityto configure their network security features as desired.

Within the VPC, the figure illustrates a first host machine 140 thathosts a VM 145 with a gateway controller 150 and a set of additionalhost machines 155 that host VMs 160 with workload applications 165. Itshould be understood that while the host machines 140 and 155 are shownas being part of the VPC, these host machines may also host additionalVMs belonging to different VPCs (of the same or other tenants) in someembodiments. As shown, each of the host machines 140 and 155 includes aforwarding element 170. In some embodiments, the host machines includeforwarding elements within their virtualization software that aremanaged by the public cloud provider. The network control system 100,however, has no access to these forwarding elements, as they are part ofthe cloud provider network.

Though shown here as a single VM 145, in some embodiments at least twoVMs with gateway controllers are instantiated in the VPC 135. One of thegateway controllers operates as an active controller and the other as astandby controller in case the active controller fails (e.g., due to thehost machine it operates on failing, the VM failing or requiring arestart, etc.). The other aspects of the gateway VM (described below)also operate in the active-standby mode as well, in some embodiments.That is, an active gateway VM and a standby gateway VM are instantiatedin some embodiments.

The VM 145, in some embodiments, is a prepackaged machine image thatincludes a gateway controller 150. The gateway controller 150 receivesdata from the MP/CCP cluster 115 (e.g., from the central control planeapplication) for all of the logical ports implemented within the VPC135. In some embodiments, in the view of the MP/CCP cluster 115, thegateway controller is equivalent to a local controller 120 for a MFEwith numerous logical ports connected (assuming there are numerouslogical ports mapped to VMs operating in the VPC 135). As such, theMP/CCP cluster 115 identifies the gateway controller 150 as a recipientfor all of the configuration rules required for any of the logical portsin the VPC 135. Though not shown here, in some embodiments the gatewayVM 145 also operates a gateway datapath for providing centralizedservices (e.g., NAT, load balancing, etc.) and for processing/routingpackets sent between the VMs 160 and external sources (e.g., via theInternet). The rules required by this datapath are also distributed tothe gateway controller 150, in some embodiments. The gateway VM of someembodiments is described in greater detail below by reference to FIG. 7.

The VMs 160 are workload VMs, each of which runs a workload application165 (e.g., a web server, application server, database server, etc.). Inaddition, to enable first-hop processing configurable by the networkcontrol system 100, each of these VMs also operates a control agent 170and a managed forwarding element 175 (e.g., a virtual switch such asOpen vSwitch). The gateway controller 150, upon receiving aconfiguration rule, identifies the span of that rule within the VPC 135(i.e., the various MFEs 175 that require the rule), and passes theseconfiguration rules to the appropriate control agents 170. The controlagent 170 uses this data to configure the MFE 175 to apply networkingand/or security rules to packet sent to and from the workloadapplication 165, similar to how the local controller 120 configures theMFEs 130.

FIG. 2 conceptually illustrates the flow of control data through thenetwork control system 100. The MP/CCP cluster 115 generates a newconfiguration rule (e.g., based on a change within the network,configuration data received by the management plane when anadministrator modifies a logical network, etc.). In some embodiments,the management plane generates this rule and provides the rule to thecentral control plane, which determines the span of the configurationrule. As shown, the MP/CCP cluster 115 passes this data 205 to the localcontrollers 120 within the private datacenter 105 that require the data.Within the private datacenter, the information is distributed via acontrol channel. The local controllers that receive this data 205convert the data into a format appropriate for the specific type of MFEpresent in its host machines. In some embodiments, the datacenter mightinclude host machines that use feature-based forwarding elements such asESX hypervisors, flow-based forwarding elements such as kernel virtualmachine (KVM) hypervisors running Open vSwitch (OVS), or other types ofsoftware forwarding elements. The local controllers 120 receive theconfiguration data 205 and convert it into the appropriate format (e.g.,flow entries for OVS), then distribute this configuration data 210 totheir local MFEs 130.

For configuration rules whose span includes the VPC 135 in the publicdatacenter 110, the MP/CCP cluster 115 sends configuration data 215 tothe gateway controller 150. The configuration data 215 is the sameformat as the configuration data 205 in some embodiments, as the MP/CCPcluster views the gateway controller as being simply another localcontroller. However, to send the configuration data 215 to the gatewaycontroller 150, some embodiments use a virtual private network (VPN)setup between the private datacenter 105 and the VPC 135. Someembodiments use the same VPN for control traffic as for logical networkdata traffic between the private datacenter and VPC, while otherembodiments use separate data. To the cloud provider forwardingelements, the control traffic appears the same as any other data beingsent over the VPN. The gateway controller 150 receives the configurationdata 215, and calculates the span within its VPC 135 for each rule. Foreach WE 175 within the VPC 135, the gateway controller 150 sends theappropriate configuration data 220 to the local control agent 170operating on the same VM as the WE. This configuration data 220 is sentto the control agents 170 through the cloud provider's network (e.g.,through the forwarding elements 170).

In addition, in some embodiments, the gateway controller 150 isresponsible for managing the overlay network within the VPC 135. Becausethe MP/CCP cluster 115 views the entire VPC as having a single managedforwarding element, the cluster only configures a tunnel endpoint forthe gateway controller node (i.e., the datapath configured on thegateway VM 145). However, for communication between the workloadapplications within the VPC (and between the workload applications andthe gateway datapath), the MP/CCP cluster does not configure theoverlay. As such, the gateway controller 150 sets up the tunnels (e.g.,STT, GENEVE, etc. tunnels) between these VMs by configuring the MAC:VTEPIP bindings, etc. The overly data (e.g., the MAC:VTEP IP bindings) isalso passed to the various control agents 170 as part of theconfiguration data 220.

Once the control agent 170 receives the configuration data, the controlagent 170 converts this data into a format specific to the WE 175 andprovides the WE-specific configuration data 225 to the MFE 175. In someembodiments, this configuration data 225 comprises flow entries for aflow-based WE and/or database entries for a WE configuration database.For instance, in some embodiments the control agent 170 uses theOpenFlow and/or OVSDB protocols to communicate with the WE 175 when theWE is an OVS instance.

As an example, initial configuration data sent from the MP/CCP cluster115 to the gateway controller might specify that a new logical port hasbeen added to a logical switch, and that logical port is attached to aMFE operating in the VPC. In this example, at least one logical port ofthe same logical switch is already attached to a different MFE operatingin the VPC. The configuration data received by the gateway controller150 does not specify the specific location because, to the CCP, thelogical port connects to the gateway.

The gateway controller 150 calculates the span of this configurationdata as the MFEs within the VPC to which all of the additional logicalports on the same logical switch connect. These MFEs need theinformation so that they can properly forward packets to the workloadapplication corresponding to the new logical port, and so the gatewaycontroller 150 distributes this data to the local control agents 170 foreach of these identified MFEs. The gateway controller 150 alsodistributes the overlay information (e.g., MAC:VTEP IP binding) for theMFE to which the new logical port connects to each of the identifiedMFEs, and distributes the overlay information for these other identifiedMFEs to the MFE to which the new logical port connects.

The control agent 170 for a particular MFE 175 uses this information togenerate logical forwarding flow entries (i.e., specifying that packetsaddressed to the MAC address associated with the logical port areforwarded logically to that logical port, as well as egress mapping andphysical forwarding (tunneling) flow entries (i.e., mapping the logicalport to the physical destination and appending the encapsulationinformation to send packets to the other MFEs) for its MFE. Similarly,the control agent 170 for the MFE 175 to which the new logical portconnects will receive information about the other logical portlocations, and generate its own corresponding flow entries so as to beable to send packets to and receive packets from the corresponding MFEs.

FIG. 3 conceptually illustrates a process 300 of some embodiments todistribute configuration data to managed forwarding elements located inboth private and public datacenters. The process 300 is performed by acentral controller (i.e., a central control plane application) in someembodiments, based on configuration data received from a managementplane application. It should be understood that, in some embodiments,the distribution of the configuration data may actually be performed bymultiple central controllers in a cluster, as different controllers inthe cluster may handle the distribution to different forwardingelements. In addition, this process assumes that the management planeand central control plane are located in a private (enterprise)datacenter. If the MP/CCP cluster is operating within a VPC of a publicdatacenter, then it performs similar span calculations for each piece ofconfiguration data and distributes the data to gateway controllers foreach VPC in which the logical network operates.

As shown, the process 300 begins by receiving (at 305) logical networkconfiguration data. As explained above, in some embodiments themanagement plane generates configuration rules for a logical networkbased on input received from an administrator (e.g., through a cloudmanagement application). The management plane provides these rules tothe central control plane. This configuration data might relate to thecreation or deletion of logical forwarding elements or logical ports ofthese logical forwarding elements, new configuration data regarding oneof these logical entities, new security group definitions or distributedfirewall rules, etc.

The process then identifies (at 310), for each atomic piece of data(e.g., each rule), the set of MFEs to receive that piece of data. Thecentral controller determines the span for each rule based on thetopology of the logical network and its physical implementation, as wellas the type of rule and logical entities (e.g., logical forwardingelements and logical ports) to which the rule pertains. For instance, adistributed network encryption rule for communication between twological ports may only need to be distributed to the MFEs to which thoselogical ports directly attach. On the other hand, a rule regarding alogical port to MAC address binding will be distributed to not only theMFE to which the logical port attaches but also to any other MFE thatmight be processing packets for which the logical port is a destination(e.g., any MFE to which a logical port attaches that could send packetsto the specific logical port without the packets requiring centralizedprocessing).

Having determined the span of each atomic piece of configuration data,the process sends (at 315) the configuration data to local controllersfor identified MFEs in the private cloud. That is, the central controlplane distributes the data to the appropriate local controllers in itssame datacenter.

The process also determines (at 320) whether the span of any of the dataincludes the logical ports located in the public cloud. As describedabove, the central control plane views all of the logical ports in apublic cloud VPC as attached to a single MFE. This process assumes asingle VPC in a single public datacenter, as shown in FIG. 1. Asdescribed below, multiple VPCs in one or more public datacenters arepossible in some embodiments, in which case a similar determinationwould need to be made for each VPC. If data needs to be sent to the MFEsin the public cloud, the process sends (at 325) this data to the gatewaycontroller operating in the public cloud. In some embodiments, the datais distributed using a VPN connection between the central controller andthe DCN on which the gateway operates.

FIG. 4 conceptually illustrates a process 400 of some embodiments fordistributing logical network configuration data to the MFEs within aVPC. The process 400 is performed by a gateway controller 400 in someembodiments, in order to distribute this data to the MFEs within itsVPCs that require the data. As shown, the process begins by receiving(at 405) logical network configuration data from a central controller.This central controller may be located in a private datacenter managedby the public datacenter tenant, in a different VPC of the same publicdatacenter as the gateway controller, or a different public datacenter.

For each atomic piece of data (e.g., each rule), the process 400identifies (at 410) the data compute nodes in the VPC to receive thedata. As mentioned with respect to FIG. 3, each rule has a span (i.e.,the MFEs that require the rule) based on the topology of the logicalnetwork and its physical implementation, as well as the type of rule andlogical entities (e.g., logical forwarding elements and logical ports)to which the rule pertains. Thus, within the VPC, each rule may not needto be distributed by the gateway controller to every control agent. Theprocess then sends (at 415) each configuration rule to the local controlagents on the data compute nodes identified for the rule. Theconfiguration data, in some embodiments, is sent over the physicalnetwork of the public cloud provider, in the same manner as standarddata packets.

The process 400 also generates (at 420) local overlay data for each datacompute node in the VPC. Because the central controller views the entireVPC as connected to a single MFE, the central controller only defines avirtual tunnel endpoint (VTEP) for the gateway VM. However, forcommunication within the VPC, the various MFEs use an overlay network aswell. Thus, the gateway controller defines the MAC:IP bindings for theseVTEPs (with the IP addresses determined based on the private (or public,depending on the configuration) IP addresses configured by the tenantfor the VMs in the VPC. The setup of these overlays will be discussed ingreater detail below in Sections IV and V.

The process then sends (at 425) the local overlay data to each of thedata compute nodes within the VPC in order to create tunnels between thedata compute nodes in the VPC. This allows the MFEs at each of thesedata compute nodes to properly encapsulate packets to be sent from theirVTEP to the VTEPs of other MFEs within the VPC (depending on the setupof the public datacenter, these packets will then be encapsulated againby the provider-controlled forwarding element on the host machine, asdescribed in more detail below).

It should be understood that the process 400 is a conceptual process andthat the gateway controller may not perform these operations in thelinear manner illustrated. For instance, some embodiments perform theoperations 420 and 425 anytime a new data compute node is created in theVPC, while the operations 405-415 are performed anytime a newconfiguration rule is received from the central controller (which willoccur when a new data compute node is created, but also anytime otherconfiguration aspects are changed).

The example shown in FIGS. 1 and 2 illustrates the case in which alogical network spans both the private datacenter 105 and a single VPC135 in the public datacenter. It should be understood that differentvariations are also possible in other embodiments. For instance, FIG. 5conceptually illustrates an example of a network control system for alogical network implemented entirely within a public datacenter 500. Inthis case, the MP/CCP cluster 505 operates on host machines 510 within afirst VPC 515. Like the gateway controller, the management plane and/orcentral control plane applications could be provided as part ofpreconfigured VM images that can be instantiated in the publicdatacenter 500. The management plane and/or central control planeapplications could operate on the same VM or VMs or on separate VMs, andeach could operate as a cluster of multiple VMs on multiple hostmachines in some embodiments. The VPC 520 is configured in the samemanner as the VPC 135 shown in FIG. 1, with a first VM 525 (or two VMsin active-standby configuration) hosting the gateway controller 530 andcontrol agents 535 managing MFEs 540 on the workload VMs 545.

FIG. 6 conceptually illustrates a network control system 600 of someembodiments that expands a logical network into multiple publicdatacenters 610 and 615. As shown in this figure, the MP/CCP cluster 620operates in a private datacenter 605, and manages MFEs in the datacentervia local controllers, as described above. In this example, the logicalnetwork is expanded into first and second public datacenters 610 and615, each of which includes a VPC with a gateway VM instance (or anactive-standby pair) and multiple host machines configured as describedby reference to FIG. 1. The MP/CCP cluster 620 views each of thesegateway controllers as akin to a single local controller, and thereforesends each of the gateway controllers all of the configuration data forthe workloads in their respective VPCs.

It should be understood that these different architectures in FIGS. 1,5, and 6 are only three of numerous possible architectures. Forinstance, a network control system could be stretched across multipleVPCs in one cloud provider, with one gateway controller (oractive-standby pair) in each VPC, or use a single gateway controller (oractive-standby pair) in one of the VPCs (or a separate VPC) to manageall of the VPCs.

II. Gateway VM Architecture

The above section describes the network controller functions (spancomputation and overlay management) of the gateway VM of someembodiments. These gateway VMs also perform several other functions insome embodiments, including interfacing with the public cloud APIs,DHCP, DNE management, and a gateway for data packets sent to and fromthe DCNs in the VPC.

FIG. 7 conceptually illustrates the architecture of such a gateway VM700 of some embodiments. As mentioned, in some embodiments, the gatewayVM is packaged as a pre-configured VM image (e.g., an Amazon MachineImage) for a specific cloud provider that the administrator of thelogical network can instantiate as one of the VMs in the publicdatacenter VPC. As shown, the gateway VM 700 includes a gatewaycontroller 705, a public cloud manager (PCM) 710, a gateway datapath715, a DNE management module 720, and a DHCP module 725. It should beunderstood that, in different embodiments, gateway VMs may includedifferent combinations of these modules as well all or some of thesemodules along with other modules.

In addition, the gateway VM includes three interfaces—a control VNIC730, an uplink VNIC 735, and a local overlay VNIC 740. In someembodiments, the control VNIC 730 is used only for control pathcommunications between the local agents on the other hosts in the VPCand the gateway controller 705, and between the MP/CCP cluster and thegateway controller 705 (as well as any communication of the DNE manager720 or PCM). Some embodiments program security groups in the cloudprovider to only allow specific traffic from the CCP and the localagents on this interface, in order to prevent denial of service (DoS)attacks from a compromised VM in the VPC. In addition, to ensure thatthe control channels stay running even when a malicious VM is sending ahigh volume of traffic to the gateway datapath 715, some embodiments pinthe gateway controller processes (and the agents operating in the otherVMs in the VPC) to specific virtual CPUs that do not perform the dataplane processing. The uplink VNIC 735 handles north-south packets sentfrom the gateway datapath 715 towards external destinations (andreceived from those external destinations), which will generally not beencapsulated by the datapath. The local overlay VNIC 740 handleseast-west data packets that the gateway datapath processes to sendpackets between workload applications within the VPC and data computenodes in other VPCs, other public datacenters, and/or the on-premisesdatacenter.

The gateway controller 705 of some embodiments performs the functionsdescribed in the above Section I. Through the control VNIC 735, acentral control plane interface 745 of the gateway controller 705receives configuration rules from the central controller and providesinformation back to the central controller (e.g., when a new VM iscreated and thus a new logical port needs to be associated with thegateway). The agent interface 750 distributes configuration data to thelocal agents operating on data compute nodes in the VPC and receivesupdates from these local agents when events occur on the data computenode (e.g., the creation of an interface on the data compute node,etc.). In some embodiments, both of these interfaces 745 and 750 arepart of a netcpa agent operating on the gateway VM.

The gateway controller 705 also includes a span manager 755 and a localoverlay manager 760. The span manager receives configuration rules sentfrom the central controller (via the CCP interface 745), determines theMFEs executing on data compute nodes within the VPC (including, possiblythe gateway datapath 715), and sends these configuration rules to theappropriate agents in the VPC. Some embodiments use different adaptersand/or different queues for each agent within the VPC, placing eachreceived rule into one or more such queues.

The local overlay manager 760 handles the management of the overlaynetwork within the VPC (for MFEs operating in overlay mode, as describedbelow in Section V). Assuming the MFEs in the VPC are operating inoverlay mode, each agent on a VM in the VPC (and the gateway datapath715) provides its VTEP IP address and MAC address bound to that VTEP IPaddress to the controller in some embodiments. The local overlay manager760 of some embodiments identifies which MFEs in the VPC require eachprovided binding, and handles the provision of this information to theMFEs in the VPC so that data packets sent to the MAC address can beencapsulated using the corresponding VTEP IP address. A first MFErequires the MAC:VTEP IP binding of a second MFE if there is thepossibility of the workload application attached to the first MFEsending a data packet to the workload application attached to the secondMFE without the data packet needing to travel through the gatewaydatapath 715.

The public cloud manager (PCM) 710 of some embodiments enables thenetwork control system to interact with the compute management system ofthe public cloud provider. Specifically, the PCM of some embodimentsuses public cloud APIs to retrieve inventory, configuration, status, andstatistics information from the public cloud provider. In the examplesshown herein, the PCM 710 operates on the gateway VM, though in otherembodiments the PCM may operate in the MP/CCP cluster (e.g., in theprivate datacenter).

As shown, the PCM includes public cloud APIs 765 and interfaces 770 and775 for communicating with the agent and with the MP/CCP cluster. Insome embodiments, the PCM only communicates directly with the managementplane, and any communications to and from the agents pass through thegateway controller. The public cloud APIs 765 are used to communicatewith the public cloud compute manager.

The gateway datapath 715 operates as a gateway in some embodiments, tohandle packet processing for data packets (i) between data compute nodeswithin its local VPC and other data compute nodes of the same logicalnetwork located in different VPCs of the same cloud provider, differentVPCs of different cloud providers, and/or the private datacenter and(ii) between data compute nodes within its local VPC andsources/destinations external to the logical network (e.g., clientsaccessing the data compute nodes through the Internet). The datapath 715shows a service router 780 (a centralized routing component of a logicalrouter of some embodiments) within the datapath, but it should beunderstood that the datapath may also include configuration for one ormore logical switches and a distributed routing component that areimplemented within the VPC.

In different embodiments, the datapath 715 may be a datapath developmentkit (DPDK)-based datapath, an OVS datapath as used in the data computenodes of some embodiments, or another type of datapath that can beimplemented within a VM. When an OVS datapath is implemented, someembodiments use the OVS datapath for the logical switch and/ordistributed router processing, while implementing a separate namespaceto handle the centralized routing component processing. On the otherhand, some embodiments that use a DPDK-based datapath implement theconfiguration for all of the logical forwarding element componentswithin the same datapath. Additional description of the gateway datapathof some embodiments is described in U.S. Patent Publication2016/0226759, which is incorporated herein by reference.

As shown, the datapath 715 uses two ports, a VTEP port 785 and an uplinkport 790, which connect to the local overlay VNIC 740 and uplink VNIC735 respectively. The gateway datapath 715 receives packets sent fromlocal workloads in the VPC via the VTEP 785, which uses an IP addressassigned by the cloud provider on the VPC subnet (i.e., on the samesubnet as the addresses assigned to the other VMs in the VPC. This VTEPport 785 is also used for packets sent to and from data compute nodes inthe private datacenter and other VPCs in the same or other publicdatacenters, as all of this traffic is encapsulated for the logicalnetwork in some embodiments.

The uplink port 790 is used by the datapath 715 to send and receivenorth-south data traffic between the workloads in the VPC and externalsources/destinations. These data packets are sent out of the uplink portwithout encapsulation (though they may be tunneled separately on thecloud provider network to a cloud provider gateway). In addition, thesepackets may require centralized services, such as NAT, distributedfirewall rules for north-south traffic, service chaining, etc.

For logical L2 switches stretched across multiple VPCs and/ordatacenters, the gateway datapath 715 acts as an intermediate forwardingelement, simply tunneling the packet (using the VTEP 785) to a similarlyconfigured gateway at another VPC or to a destination forwarding elementin the private datacenter (via a VPN). Some embodiments additionallyperform security operations (e.g., applying distributed firewall rulesfor such packets), and decrypt and then re-encrypt (in order to examineand potentially process) packets that are sent between two endpointsrequiring encryption. Packets sent between two different logicalswitches may also require the service router processing 780 ifcentralized services (NAT, load balancing, etc.) are required for suchpackets.

The DNE manager 720 interacts with the network control system in orderto manage encryption rules and keys for the data compute nodes locatedin the network. When the central control plane receives rules specifyingencryption and/or authentication requirements for packets sent to orfrom any of the workloads operating in the local VPC, the centralcontroller distributes these rules to the DNE manager 720 (eitherdirectly or via the gateway controller 705). As described in more detailbelow and in U.S. Patent Application 62/380,338, filed Aug. 26, 2016 andwhich is incorporated herein by reference, the encryption rules of someembodiments include a ticket used by a controller (in this case, the DNEmanager) to acquire a key from a key storage (also referred to as keymanager), often located in the private datacenter.

The DNE manager 720 uses this ticket to request a key from the keymanager, which provides a master key for the encryption rule. The DNEmanager 720 receives the master key and uses this key to generate asession key for the rule. The session key, in some embodiments, isgenerated as a function of the master key and one or more additionalparameters specific to the two endpoints that will be performingencryption. The DNE manager (e.g., via the gateway controller 705)distributes the generated session keys to the appropriate endpoints.

Finally, the DHCP module 725 acts as a DHCP server to perform IP addressmanagement within the VPC. Some embodiments use the same DHCP module 725for multiple subnets if multiple logical switches are implemented withinthe VPC. When a VM in the VPC boots up, in some embodiments it uses theDHCP server in its local gateway in order to receive its networkaddress.

III. Initial VPC Configuration

While the above sections describe the extension of the control planeinto a VPC and the gateway controller that enables this extension, thesevarious components within the VPC must be initially configured andbrought on-board with the management plane and central control plane insome embodiments. In some embodiments, the initial setup of the networkand control system in the public cloud is managed by an operationsmanager (also referred to as a life cycle manager, or LCM). The networkadministrator interacts with this LCM (e.g., via a user interface) whichuses the public cloud credentials of the network administrator to accessthe LCM and initially configure the various VMs in the VPC.

FIG. 8 conceptually illustrates a process 800 of some embodiments toinitially extend a network control system managing a private datacenterinto one or more VPCs of a public datacenter. The process 800 isperformed, in some embodiments, by a life cycle manager (LCM) thatinteracts with the private datacenter management systems (e.g., with thecompute manager) to perform this initial setup. The LCM is differentfrom the PCM described above, as the LCM handles initial configurationof the DCNs in the public datacenter (including the gateway DCN on whichthe PCM runs), while the PCM handles ongoing interaction with the publicdatacenter management system. It should be understood that the process800 is only one possible workflow for the LCM, and assumes that DCNs arealready instantiated in the public datacenter. Other workflows mightexist in some embodiments, for example for the case in which VPCs havebeen defined but DCNs do not yet exist in these VPCs.

As shown, the process 800 begins by receiving (at 805) administratorcredentials for the public cloud provider of the datacenter within whichthe network will be configured. The credentials may include a usernameand password, as well as potentially other credentials required by thedatacenter. The LCM of some embodiments may provide a single interfacethat allows the user to interact with multiple public cloud providers,such as Amazon, Google, Microsoft, etc. in a unified manner, and throughwhich the user inputs these credentials. The process then uses (at 810)these credentials to retrieve a list of VPCs in the public cloud thatare registered to the user. For this, the LCM provides these credentialsto an interface of the public cloud management system, and is providedwith the requested data regarding the user's VPCs. In some embodiments,the user will have already configured a number of VPCs in the publiccloud, with subnets allocated, etc.

Next, the process 800 receives (at 815) an identification from theadministrator/user as to which VPCs will be managed by the networkcontrol system. These are the VPCs into which the logical network willbe extended in some embodiments. In some embodiments, the LCM presentsthe list through a user interface to the administrator, who then selectssome or all of the available VPCs through the interface. The processautomatically deploys (at 820) a gateway instance in each of theidentified VPCs. The gateway instance, in some embodiments, is a VMhaving the components described above in Section II. As mentioned, insome embodiments each gateway VM is an instance of a prepackaged machineimage specifically designed for the public cloud provider into whosedatacenter the gateway VM is deployed.

In addition, the process 800 retrieves (at 825) a list of DCNs (e.g.,VMs) in the VPCs identified by the administrator. As with the retrievalof the VPCs, in some embodiments the LCM queries the public cloudmanagement system for this information. The process receives (at 830) anindication from the administrator as to which of the existing DCNsshould be managed by the network control system, as well as aspecification of the logical switches and/or security groups for theseDCNs. In this case, the logical network topology and security groupdefinitions have already been configured, and the DCNs in the publiccloud are mapped to these entities. The process 800 provides (at 835)the logical switch and security group mappings to the management plane,so that the appropriate configuration rules can be generated anddistributed via the network control system for processing packets sentto and from these DCNs.

The above process describes the LCM instantiating a gateway DCN in apublic cloud; however, the gateway controller on that gateway DCN willalso need to be certified with the MP/CCP cluster in some embodiments,in order to receive data from the central controllers. FIG. 9conceptually illustrates a process 900 of some embodiments forcertifying a gateway controller with the management and control planes.The process 900 is performed by the gateway controller uponinstantiation of a gateway DCN containing the gateway controller.

As shown, the process 900 begins by identifying (at 905) a managementplane certificate and IP address. In some embodiments, the managementplane certificate is provided with the instantiation of the gateway DCNfor a particular management plane instance or cluster of instances. Insome embodiments, this information is provided with the gateway DCN(e.g., in a configuration file to which the gateway controller hasaccess). The process also generates (at 910) a shared secret used for asecure communication channel with the management plane. Some embodimentsgenerate this shared secret based on a command-line interface (CLI)command input by the administrator or the LCM.

Next, using the shared secret and the management plane IP address, theprocess 900 connects (at 915) to the management plane and verifies theauthenticity of the management plane (i.e., to ensure that it hasconnected to an authorized management plane application). In someembodiments, the management plane application provides its certificate(or a value, such as a hash, generated from the certificate) and thegateway verifies that the certificates match. The process also registers(at 920) its own certificate with the management plane. This certificateis also verified by the management plane in some embodiments. At thispoint, the gateway has a connection to the management plane cluster, butnot the central control plane, and thus cannot receive configurationrules.

Next, the process 900 receives (at 925) a central control planecertificate from the management plane, via the communication channel setup with the management plane. Using the central control planecertificate, the process activates (at 930) a channel with the centralcontrol plane. The management plane will have provided the gatewaycertificate to the central control plane, which verifies that thecertificate received from the gateway matches this certificate.Similarly, the gateway controller verifies that the certificate receivedfrom the central control plane matches that received from the managementplane. With this channel set up, the gateway controller can beginreceiving configuration data from the central control plane, once thecentral control plane determines which configuration data to distributeto the gateway controller.

Once the gateway is onboarded with the management plane and centralcontrol plane, the agents in the DCNs of the VPC can be similarlyonboarded. However, unlike the gateway or a local controller in theprivate datacenter, these local agents do not communicate with theMP/CCP cluster operating in the private datacenter, because theseentities view the gateway controller as the controller for all of theselogical ports. Thus, these agents only verify themselves with thegateway controller.

FIG. 10 conceptually illustrates a process 1000 of some embodimentsperformed by a local control agent executing in a DCN in a public cloudVPC to certify itself with the gateway controller for that VPC. Asshown, the process 1000 begins by identifying (at 1005) a gateway nameand certificate. In some embodiments, the gateway name is provided as aURL within a configuration file for the control agent (e.g.,nsx-gw.aws.com). This configuration file also includes a list ofinterfaces and their type (e.g., overlay or non-overlay) in someembodiments. The process resolves (at 1010) the gateway IP address basedon the gateway name. For instance, some embodiments use a DNS serverwithin the datacenter to resolve the gateway name to its IP addresswithin the VPC.

The process 1000 then initiates (at 1015) a control channel to thegateway controller. The process sends (at 1020) its own agentcertificate to the gateway and receives the gateway certificate from thegateway via this control channel. In some embodiments, the gateway isauthorized to trust the agent certificate on first use, rather thanrequiring certificates for every agent to have been pre-registered withthe gateway. However, the process 1000 on the agent does verify (at1025) the certificate received from the gateway to ensure that it hasconnected to a valid gateway controller.

IV. Physical Implementation of Logical Topology

As mentioned above, by expanding a logical network into one or morepublic datacenters, a logical topology may be stretched across thesedatacenters. Some embodiments confine the VMs attached to a givenlogical switch to one VPC (or the private datacenter), while otherembodiments allow for even a single logical switch to be stretchedacross multiple VPCs or multiple datacenters.

FIG. 11 conceptually illustrates a logical topology 1100 of someembodiments, as an administrator might input the topology into themanagement plane. As shown, the logical topology 1100 includes a logicalrouter 1105 and two logical switches 1110 and 1115. Four virtualmachines are attached to the logical switch 1110, and the logical routerincludes an uplink port to an external network. In this case, only onetier of logical router is shown in the logical network, although someembodiments could also include multiple tiers of logical routers. Inaddition, the management plane of some embodiments might define severallogical routing components (e.g., a distributed router and one or morecentralized service routers) for the logical router 1105. The multipletiers of logical routers and creation of multiple routing components fora logical router are described in further detail in U.S. PatentPublication 2016/0226754, which is incorporated herein by reference.

The logical switches 1110 and 1115 attached to the logical router areeach assigned a subnet, in some embodiments, and thus the workload VMscreated to attach to a particular logical switch should be assigned IPaddresses in the appropriate subnet. However, as described in greaterdetail below in Section V.B, in some embodiments the IP address of theVM with regard to the cloud provider is different than the IP address ofthe logical port mapped to that VM, as the IP address facing the cloudprovider network is that of the tunnel endpoint created for the MFEoperating on the VM. In this case, the logical switch 1110 is assignedthe subnet 192.168.1.0/24. In addition, four VMs are shown attached tothe logical switch 1110.

FIG. 12 illustrates an example of four VMs 1205-1220 attached to thelogical switch 1110, as implemented within a single VPC 1200 of a singlepublic cloud provider. In this example, all of the VMs attached to thelogical switch 1110 are instantiated in the same VPC, with only the VMsattached to that logical switch instantiated in the VPC. This VPC 1200is assigned a subnet 10.1.0.0/16, which may be a public or privatesubnet depending on how the administrator has configured the VPC on thepublic cloud. In this example (and the other examples in this section),the MFEs are all operating in overlay mode, such that the VM IP addressis different than the workload application IP address (i.e., the IPaddress associated with the logical switch port).

As shown, each of the VMs is assigned a different workload IP in the192.168.1.0/24 subnet (192.168.1.1, 192.168.1.2, 192.168.1.3, and192.168.1.4 respectively). When the workload application sends a packet,this IP address will be the source IP used in the header of that packet.However, the MFEs operating on these VMs have VTEPs with different IPaddresses on the 10.1.0.0/16 subnet (10.1.0.1, 10.1.0.2, 10.1.0.3, and10.1.0.4 respectively). The packets that exit the VM will thus beencapsulated using this VTEP IP address as the source IP address (afterlogical processing is performed by the MFE in the source VM), in orderto be sent to other destinations in the VPC.

The figure also illustrates tunnels between these four MFEs and agateway 1225 in the VPC. These tunnels pass through the underlyingnetwork of the public cloud provider (referred to herein as the“underlay”). In addition, though not shown here for simplicity, tunnelsare created (through the underlay network) between each pair of the MFEsoperating on the VMs 1205-1220. The gateway can also send packets to(and receive packets from) destinations within the on-premises privatedatacenter 1230. To send these packets, the gateway 1225 encapsulatesthe packets using its VTEP IP (10.1.0.5), so that the destination willidentify the incoming packet as a logical network packet. To securetraffic between the gateway 1225 in the VPC 1200 and the destinations inthe private datacenter 1230 (e.g., VMs attached to logical switch 1115),the packets are sent via a VPN tunnel 1235 in some embodiments. In thisexample, the gateway's connection to external networks is not shown, asthis will be discussed in more detail in sections below pertaining tocentralized and distributed network address translation and otherservices.

FIG. 13 illustrates an example in which the logical switch 1110 isstretched across two separate VPCs 1300 and 1305 within a singledatacenter (i.e., of the same cloud provider). In this case, four VMs1310-1325 have the same IP addresses for their workload applications ona single subnet (192.168.1.0/24). However, because the two VPCs havedifferent subnets (the first VPC is assigned 10.1.0.0/16 and the secondVPC is assigned 10.2.0.0/16), the VTEPs of the MFEs are not all on thesame subnet. Thus, the VTEPs on the two VMs 1310 and 1315 in the firstVPC 1300 are assigned IP addresses 10.1.0.1 and 10.1.0.2, while theVTEPs on the two VMs 1320 and 1325 in the second VPC 1305 are assignedIP addresses 10.2.0.1 and 10.2.0.2.

Gateways 1335 and 1340 are also instantiated within each of the VPCs,and each has a VTEP on the subnet of its respective VPC. In thesituation in which the VPCs are not peered, then packets sent betweenthe two gateways are sent using a VPN connection (i.e., the VPCs mightas well be located in separate datacenters). However, some cloudproviders enable peering of VPCs, in which case packets can be sentdirectly from one endpoint in one of the VPCs to a second endpoint inanother peered VPC. Thus, if the two VPCs 1300 and 1305 are peered, thenpackets sent from one of VMs 1310 and 1315 to one of VMs 1320 and 1325need not be sent via the VPN 1330. In fact, some embodiments do not evenrequire these packets to be sent through the gateways 1335 and 1340, butcan be tunneled through the provider network directly from one VM to theother. However, if the VPCs 1300 and 1305 are not peered, then suchinter-VPC packets should be sent from the VM to its gateway via anintra-VPC tunnel, from the first gateway to a second gateway in thedestination VPC via a VPN, and from the second gateway to thedestination VM.

For connection to the private datacenter 1345 (e.g., to reach VMsattached to the second logical switch 1115), the gateways use the VPN1330. This VPN 1330 is representative of various possible VPNconfigurations used to link the private datacenter with one or more VPCsat one or more cloud providers. For instance, some embodiments use afull mesh of VPN tunnels between each destination, while otherembodiments use a hub-and-spoke VPN or a combination of the two. Inaddition, different embodiments may use a VPN provided by the publiccloud provider or by the network control system, or a combinationthereof (e.g., if using a mesh of VPNs).

FIG. 14 illustrates a similar configuration to that of FIG. 13, but withthe VMs 1410-1425 attached to the logical switch 1110 stretched acrossVPCs 1400 and 1405 that are located in datacenters of two completelydifferent cloud providers. This situation differs from that of FIG. 13in that there is generally no option to peer VPCs between two differentdatacenters (and especially two different datacenters of different cloudproviders), so any communication between workloads in the datacenterswill be sent via the VPN 1430. As in the discussion of FIG. 13, someembodiments may use a hub-and-spoke VPN in the multi-public cloudconfiguration, while other embodiments use separate VPN connections for(i) each public cloud to the other and (ii) each public cloud to theprivate data-center.

In addition to the examples shown in these figures, it should beunderstood that other configurations are possible. For example, a singlelogical switch could be stretched between the private datacenter and oneor more public datacenters. In any of FIGS. 12-14, one or more of theVMs attached to the logical switch could be implemented within theon-premises datacenter rather than in one of the public cloud VPCs.

V. MFE Configuration in Workload VM

As described above, in order to enable the network control system toconfigure packet processing rules for data traffic sent to and fromworkload DCNs in the public cloud, some embodiments install managedforwarding elements in the workload DCNs along with local control agentsto configure the MFEs. This MFE is connected to the DCN's networkinterface, such that all packets sent to and from the workloadapplications running in these DCNs pass through (and are processed by)the MFE according to configuration data installed by the local controlagent.

These MFEs may be configured differently in different embodiments of theinvention. For example, some embodiments configure the MFEs innon-overlay mode, in which the IP address of the workload application isthe same as the IP address of the DCN's network interface. In this case,the MFE does not perform any packet processing, and instead isconfigured to perform micro-segmentation and/or network securityprocessing such as distributed firewall rule processing. In otherembodiments, the MFEs are configured such that an interface to which theworkload application connects has a different IP address than theoutward-facing interface of the DCN, used for the VTEP. In this case,the MFE performs packet forwarding according to the logical networkconfiguration in addition to any network security or other processing.Finally, the administrator may want to keep the same IP addresses forworkloads that are already in existence but make use of the logicalnetwork for packet processing, tunneling, etc. In this third case, theMFE is configured in a separate namespace of the DCN from the workloadapplication. This enables the workload application to connect to aninterface having its existing IP address, and then use a veth pair toconnect this interface to the MFE in its separate namespace, which usesthe same IP address for its VTEP.

A. MFE in Non-Overlay Mode

FIG. 15 conceptually illustrates a VM 1505 with a managed forwardingelement 1500 configured in non-overlay mode. In this example, the MFE isan Open vSwitch (OVS) instance. In all of these examples, the MFE isconfigured to include two bridges—an integration bridge (to which theapplication workload connects via the network stack of the VM), and aphysical interface (PIF) bridge that connects to the virtual networkinterface controller (VNIC) of the VM.

As shown in this figure, the workload application 1510 (e.g., a webserver, application server, etc.) operating on the VM 1505 connects viaan internal port to the integration bridge 1515 of the MFE. Thisinternal port is associated with the network stack of the VM, and thushas the IP address of the VM as provided by the public cloud provider(e.g., the 10.1.0.0/24 IP address in the example of FIG. 12). Theintegration bridge 1515, in some embodiments, does not performforwarding or encapsulation. Instead, the integration bridge 1515automatically forwards all packets to the PIF bridge 1520 via a patchport, after performing any security processing (assuming the packet isnot dropped or denied).

The integration bridge also processes packets received from theapplication 1510 (or from the PIF bridge and send to the application1510) using flow entries that implement any network security or othernon-forwarding policies. For instance, the integration bridge implementsDFW rules that apply to the logical port to which the VM 1505 attaches.These rules may be specified in terms of source and/or destination MACaddresses, and may allow, drop, deny, etc. packets sent to or from thesespecified addresses and/or under specific conditions (e.g., connectionopenings), in some embodiments. In addition, different embodiments mayimplement a combination of logging, distributed encryption rules (bothencryption for outgoing packets and decryption for incoming packets),and tunneling to third party service appliances (e.g., middleboxappliances).

FIG. 16 illustrates an example of packet processing through a VPC byMFEs operating in non-overlay mode, specifically showing a firstworkload application 1605 sending a packet to another workloadapplication 1610 on the same VPC. FIG. 16 includes two host machines1615 and 1620 operating VMs in the same VPC in a public datacenter. Afirst VM 1625 operates on the first host machine 1615, with a workloadapplication 1605 and a MFE 1635 executing in the first VM. A second VM1630 operates on the second host machine 1620, with a workloadapplication 1610 and a MFE 1640 executing in the second VM. In thiscase, both of the MFEs operate in non-overlay mode. In addition, each ofthe host machines 1615 and 1620 includes respective public cloudforwarding elements 1645 and 1650 to which their respective VMs connect.These public cloud forwarding elements may be software virtual switches(and, in fact could be the same type of virtual switch as the MFEs 1635and 1640). However, unlike the MFEs 1635 and 1640, the network controlsystem does not have access to these forwarding elements, as they arecontrolled by the public cloud provider.

As shown, the first workload application 1605 sends a packet 1655 to theMFE 1635 on its VM 1625. The packet 1655 includes source and destinationIP addresses, various headers (e.g., TCP/UDP, IP, Ethernet, etc.), aswell as a payload. As used in this document, a packet refers to acollection of bits in a particular format sent across a network. Itshould be understood that the term packet may be used herein to refer tovarious formatted collections of bits that may be sent across a network,such as Ethernet frames, IP packets, TCP segments, UDP datagrams, etc.While the examples below refer to packets, it should be understood thatthe invention should not be limited to any specific format or type ofdata message.

The MFE 1635, upon receiving the packet 1655, applies any applicablesecurity policies (e.g., firewall rules) or other non-forwardingpolicies with which it has been configured by the local control agent(not shown). Assuming the packet is not dropped, the MFE 1635 outputsthe packet 1655 from the VM interface, which connects to the publiccloud forwarding element 1645. Assuming the public cloud network usestunneling between host machines, the public cloud forwarding element1645 encapsulates the packet with its own underlay encapsulation andsends this encapsulated packet 1660 out over the physical cloud providernetwork. The underlay encapsulation uses the IP of an interface of thefirst host machine 1615 as its source address and the IP of an interfaceof the destination host machine 1620 as its destination address.

The packet 1660 is then received by the host machine 1620 anddecapsulated by the public cloud forwarding element 1650. The forwardingelement 1650 sends the packet 1655 to the interface of the workload VM1630 based on its destination address, where the MFE 1640 processes thispacket. The MFE 1640 performs its network security processing, anddelivers the packet to the workload application 1610. In someembodiments, the MFEs at both the source and destination perform networksecurity, in case the source VM and its MFE are compromised by anattacker.

Because the network control system is not providing any forwarding, insome embodiments a logical switch cannot span more than one VPC (the L2domain is restricted to the underlying VPC subnet). In addition, L3forwarding is limited to routing within the VPC or between VPCs usingpeering or VPNs. However, the non-overlay mode does allow theapplications to continue operating on the IP addresses from the cloudprovider, thereby facilitating easy seamless integration with otherservices provided by the cloud provider, such as storage or loadbalancing services. North-south traffic uses the gateway datapath as adefault gateway, in which case a separate routing table provided by thecloud provider and attached to the northbound interface of the gatewaypoints to the cloud provider's internet gateway as the default gateway.

B. MFE in Overlay Mode

FIG. 17 conceptually illustrates a VM 1705 with a managed forwardingelement 1700 configured in overlay mode, with distinct IP addresses for(i) the internal port used by the application and (ii) the VTEP thatencapsulates packets to be sent to other VMs on the same VPC. As in FIG.15, the MFE 1700 is an OVS instance configured with an integrationbridge 1715 and a PIF bridge 1720. The workload application 1710 (e.g.,a web server, application server, etc.) operating on the VM 1705connects via an internal port to the integration bridge 1715 of the MFE.However, in this case, the internal port is associated with a networkstack for an IP address corresponding to the logical port to which theworkload is attached, and thus belonging to the subnet of the logicalswitch with which the logical port is associated (e.g., the192.168.1.0/24 addresses in FIG. 12).

In this case, the integration bridge 1715 performs logical L2 and/or L3processing for packets sent to and from the workload application 1710.This may include ingress and egress context mapping and ingress andegress ACLs for each logical forwarding element in the logical topology,as well as logical switching and/or routing. In addition, theintegration bridge performs distributed firewall, distributedencryption, tunneling to third-party service appliances, etc. in someembodiments, as in the case of the non-overlay MFEs.

Unlike the MFE 1500, the MFE 1700 is not configured with a patch port tosend packets between the two bridges. Instead, the integration bridge1715 includes an overlay port that connects to a VTEP on the PIF bridge1720 (e.g., via a second network stack for the cloud provider IPaddress). This VTEP has the cloud provider IP address (e.g., the10.1.0.0/16 addresses in FIG. 12), which the integration bridge 1715uses to encapsulate packets sent out of the VM 1705, and which is usedby other MFEs in the same VPC, including the gateway datapath, to tunnelpackets for the workload application to the MFE 1700. These packets sentto the VTEP IP address (via the VNIC of the VM 1705, which has the cloudprovider IP address) are decapsulated by the integration bridge 1715before delivery to the workload application 1710.

FIG. 18 illustrates an example of packet processing through a VPC byMFEs operating in overlay mode, specifically showing a first workloadapplication 1805 sending a packet to another workload application 1810on the same VPC. FIG. 18 includes two host machines 1815 and 1820operating VMs in the same VPC in a public datacenter. A first VM 1825operates on the first host machine 1815, with a workload application1805 and a MFE 1835 executing in the first VM. A second VM 1830 operateson the second host machine 1820, with a workload application 1810 and aMFE 1840 executing in the second VM. In this case, both of the MFEsoperate in overlay mode, with internal IPs associated with logicalswitch ports and VTEP IPs associated with the VPC subnet of the cloudprovider. In addition, each of the host machines 1815 and 1820 includesa respective public cloud forwarding element 1845 and 1850 to whichtheir respective VMs connect. These public cloud forwarding elements maybe software virtual switches (and, in fact could be the same type ofvirtual switch as the MFEs 1835 and 1840). However, unlike the MFEs 1835and 1840, the network control system does not have access to theseforwarding elements, as they are controlled by the public cloudprovider.

As shown, the first workload application 1805 sends a packet 1855 to theMFE 1835 on its VM 1825. The packet 1855 includes source and destinationIP addresses, various headers (e.g., TCP/UDP, IP, Ethernet, etc.), aswell as a payload. In this case, the source IP address is the internalIP address of the workload application (rather than the VM interface IPaddress).

The MFE 1835, upon receiving the packet 1855, performs logicalforwarding in addition to any application security policies (e.g.,firewall rules) according to its configuration by the local controlagent. If the destination MAC address of the packet is on the samelogical switch as the sending workload, then the processing through thetopology will only include the L2 processing for that logical switch. Ifthe destination is on a different logical switch, then the logicalprocessing will include processing for the source logical switch,processing for at least one distributed logical router, and processingfor the logical switch to which the destination MAC address attaches(possibly in addition to any transition logical switches between logicalrouting components), if multiple routing components are involved.

Assuming that the packet is not dropped, the MFE 1835 encapsulates thepacket 1855 so as to tunnel the packet to its destination (using, e.g.,GENEVE, STT, etc.), and outputs this encapsulated packet 1860 from theVM interface, which connects to the public cloud forwarding element1845. If the public cloud network uses tunneling between host machines,the public cloud forwarding element 1845 encapsulates the packet asecond time with its own underlay encapsulation and sends thistwice-encapsulated packet 1865 out over the physical cloud providernetwork. The underlay encapsulation uses the IP of an interface of thefirst host machine 1815 as its source address and the IP of an interfaceof the destination host machine 1820 as its destination address.

After traveling through the underlay (cloud provider) network, thepacket 1865 is received by the host machine 1820, where the public cloudforwarding element 1850 removes the outer (underlay) encapsulation. Theforwarding element 1850 sends the once-encapsulated packet 1860 to theinterface of the workload VM 1830 based on the destination VTEP address,where the MFE 1840 processes this packet. The MFE 1840 removes theoverlay encapsulation, performs any additional logical processing andnetwork security processing, and delivers the inner packet 1855 to theworkload application 1810.

The workload application may also send packets to destinations on thelogical network but located outside the VPC (e.g., at a different VPC ofthe same datacenter, at a different public datacenter of the same or adifferent cloud provider, or at the tenant's own private datacenter). Insome embodiments, these packets are tunneled to the gateway within theVPC and sent out via VPN (or another secure manner) to the destinationat another datacenter. The destination could be on the same logicalswitch (as in the examples shown in Section IV above), or on a separatelogical switch (in which case the gateway might provide centralizedrouter processing, if required).

FIG. 19 illustrates an example of packet processing through a VPC byMFEs in overlay mode for a packet sent to a logical network destinationoutside the VPC. FIG. 19 includes two host machines 1915 and 1920operating VMs in the same VPC in a public datacenter. A workload VM 1925operates on the first host machine 1915, with a workload application1905 and a MFE 1935 (in overlay mode) executing in the workload VM. Agateway VM 1930 operates on the second host machine 1920, with a gatewaydatapath 1910 executing on the VM (in addition to a controller, PCM,etc. that are not shown here as they do not participate in the packetprocessing). As mentioned, the MFE 1935 operates in overlay mode, withan internal IP address associated with the logical switch port to whichthe workload attaches and a VTEP IP address associated with the VPCsubnet of the cloud provider. In addition, each of the host machines1915 and 1920 includes a respective public cloud forwarding element 1945and 1950 to which their respective VMs connect. As in the previouscases, these public cloud forwarding elements may be software virtualswitches, to which the network control system does not have access.

As shown, the workload application 1905 sends a packet 1940 to the MFE1935 on its VM 1925. As with the previous packets, this packet 1940contains source and destination IP addresses (and source and destinationMAC addresses), various headers, and a payload. As with the previousfigure, the source IP address is the internal IP address of the workloadapplication 1905 (not the VM interface IP address). The destination IPaddress of the packet corresponds to a logical network destinationlocated outside of the VPC (and outside of a peered VPC in the samedatacenter). This could be a DCN located in a private datacenter, adifferent public datacenter (from the same or different provider), etc.If the destination is on the same logical switch as the workloadapplication, then the destination MAC address in the packet 1940 is alsothat of this destination. On the other hand, if the destination is on adifferent logical switch, then the destination MAC is that of thelogical router port to which the workload's logical switch connects.

The MFE 1935, upon receiving the packet 1940, performs logicalforwarding in addition to any application security policies (e.g.,firewall rules) according to its configuration by the local controlagent. If the destination MAC address of the packet is on the samelogical switch as the sending workload, then the processing through thetopology will only include logical switch processing for that logicalswitch. If the destination is on a different logical switch, then thelogical processing will include processing for the source logical switch(to which the workload application 1905) attaches, processing for atleast one distributed router, and processing for the logical switch towhich the destination MAC address attaches. In either case, the MFEidentifies the destination logical switch port as mapping to the gatewayVTEP (as all logical ports external to the VPC map to the gateway).

Assuming the packet is not dropped (e.g., based on distributed firewallrules), the MFE 1935 encapsulates the packet 1940 so as to tunnel thepacket to the gateway (using, e.g., GENEVE, STT, etc.) and outputs thisencapsulated packet 1955 from the VM interface, which connects to thepublic cloud forwarding element 1945. As shown, the source IP addressfor this encapsulation is that of the VTEP of the MFE 1935 (i.e., theaddress of the VM interface), while the destination IP address is thatof the VTEP of the gateway datapath 1910 (i.e., the address of thegateway VM interface used for tunnel traffic).

Assuming the public cloud forwarding network uses tunneling between hostmachines, the public cloud forwarding element 1945 encapsulates thepacket a second time with its own underlay encapsulation and sends thistwice-encapsulated packet 1960 out over the physical cloud providernetwork. The underlay encapsulation uses the IP addresses of interfacesof the host machines 1915 and 1920 as its source and destination IPaddresses, respectively.

After traveling through the underlay (cloud provider) network, thepacket 1965 is received by the host machine 1920, where the public cloudforwarding element 1950 removes the underlay encapsulation. Theforwarding element 1950 sends the still-encapsulated packet 1955 to thegateway VM 1930, via the gateway VM's interface for tunneled traffic,based on the destination IP address of the overlay encapsulation. Thegateway datapath 1910 processes this packet 1955 by removing theencapsulation, identifying the destination logical port for the innerpacket 1940, and mapping this port to a destination tunnel endpoint. Inthis specific example, the destination maps to an on-premises MFE (i.e.,in the tenant's own private datacenter). Some embodiments use this asthe tunnel endpoint, while other embodiments tunnel the packets to agateway for the private datacenter). As shown, for the new encapsulatedpacket 1965, the source IP address is that of the gateway VTEP (i.e.,the destination address of the original encapsulated packet 1955), whilethe destination is the VTEP of the on-premises MFE. In addition, toreach its destination at the private datacenter, the encapsulated packet1965 is sent through a secure VPN tunnel, as the packet may need totraverse the Internet to reach the destination datacenter. This VPNtunnel may be applied at the gateway in some embodiments, or by aseparate VPN gateway provided by the public cloud provider. TheVPN-tunneled packet 1970 is then sent out of the datacenter.

C. MFE in Overlay Mode with Single IP

In some cases, a datacenter tenant may want to impose their own networkcontrol system on an existing set of DCNs operating in the publicdatacenter, but do so without modifying the IP address of the workloads.To handle this need, some embodiments enable the MFEs in the publicdatacenter DCNs and the workload application (e.g., web server,application server, etc.) to operate in different namespaces of the DCN.This enables the two namespaces to have independent network stacksassociated with the same IP address (as opposed to the standard overlaymode described above in subsection B, in which two network stacksoperating in the same namespace cannot be associated with the same IPaddress.

FIG. 20 conceptually illustrates a VM 2000 with a managed forwardingelement configured in overlay mode, but using the same IP address forthe internal port as for the VTEP port. As in the previous examples, theMFE is an OVS instance configured with an integration bridge 2015 and aPIF bridge 2020. However, in this case, the VM 2000 includes both a rootnamespace 2005 and a second namespace 2010, referred to as the MFEnamespace as the MFE bridges are instantiated within this secondnamespace.

The workload application 2025 operating on the VM 2005 executes in theroot namespace 2005, which is what a user of the VM (as opposed to thenetwork administrator) would normally see when logged into the VM. TheMFE namespace 2010 includes the integration bridge 2015 and the PIFbridge 2020, which operate in the same manner as for the MFE 1700described above. That is, the integration bridge 2015 performs logicalL2 and L3 processing for packets sent to and from the workloadapplication 2025. This may include egress and ingress ACLs for eachlogical forwarding element in the logical topology as well as logicalswitching and/or routing. In addition, the integration bridge 2015performs distributed firewall, distributed encryption, tunneling tothird-party service appliances, etc. as in the other modes of the MFEs.In addition, there is no patch port configured to send packets betweenthe two bridges 2015 and 2020 in this case. Instead, the integrationbridge 2015 includes an overlay port that connects to a VTEP on the PIFbridge 2020.

However, the use of two different namespaces allows both the VTEP on thePIF bridge and the application 2025 to both use the same IP address fromthe cloud provider (i.e., the IP address associated with the VNIC 2030of the VM 2000). Different network stacks running in each of the twonamespaces are both allowed to be associated with the same cloudprovider IP address. These two namespaces 2005 and 2010 are connected bya veth (virtual network interface) pair, that connects these vethinterfaces configured on each of the two namespaces.

Thus, when the workload application sends a packet to a logical networkdestination (either in the same VPC or in a different VPC/datacenter),the packet (having the cloud provider IP as its source IP) is sentthrough the veth pair to the integration bridge 2015, which performs therequisite logical network processing on the packet. The integrationbridge 2015 also encapsulates these packets to be sent to another VM onthe VPC (either a workload VM or the gateway VM). The source IP in theencapsulation header is the same as the source IP of the inner packet.However, the encapsulation is still used, as the logical network of someembodiments uses the encapsulation header to carry additional contextinformation (e.g., regarding the logical processing performed by theintegration bridge). Similarly, packets sent to the workload application(from the gateway or other MFEs in the VPC) will be received at the PIFbridge 2020 with the same destination IP address for both their innerand outer headers. The integration bridge removes the outer(encapsulation) header and identifies any logical context, then deliversthe packet through the veth pair to the workload application (i.e., tothe network stack in the root namespace). Thus, the packet processing bythe MFE, public cloud forwarding elements, gateway, etc. is similar tothat shown in FIGS. 18 and 19, in terms of the input and output from thevarious components shown in those figures, although the internalworkings of the MFEs are different.

VI. NAT and Other Services

In the above section V, the packet processing examples all relate toeast-west traffic originating from a workload DCN in a public cloud VPC(either sent to another workload in the VPC or in a differentdatacenter, but still attached to the logical network), and focus on thedifferent types of processing performed by the MFEs operating in thoseworkload DCNs. However, many logical networks include workloads thatshould be accessible by external clients. For instance, a typicalthree-tier (web servers, app servers, database servers) setup willrequire at least the web servers to be able to connect with clients viathe Internet. Because the VPC subnets are typically private IP addressesthat may be re-used by numerous VPCs of different tenants within adatacenter (and re-used at various different datacenters), networkaddress translation (NAT) is generally used to modify the source IPaddress of outgoing packets (and, correspondingly, the destination IPaddress of incoming packets) from the internally-used private IP addressto a public IP address.

Furthermore, when the logical network is implemented at least partiallyin a public datacenter, the actual translation to a public IP addressmight need to be performed by the cloud provider's internet gateway,rather than by any of the managed forwarding elements. The cloudprovider gateway will be the last hop within the datacenter for thepackets, and while internal to the datacenter they will need to have theprivate IP address. However, because the cloud provider will not haveassigned the internal IP addresses used by the workload applications(the addresses corresponding to the logical switch ports), packetsshould not be sent to the provider's gateway using these addresses.Instead, the MFEs managed by the network control system of someembodiments perform their own NAT to translate the internal IP addressesto addresses registered with the cloud provider.

Different embodiments may implement this network address translation indifferent manners. Some embodiments apply NAT as part of the gatewaydatapath. In this case, north-bound packets are tunneled from the sourceMFE to the gateway, where the IP address is translated in a consistentmanner to a secondary IP address. Some embodiments use a NAT table thatmaps each internal workload IP address to a secondary IP addressregistered with the cloud provider. All of these secondary IP addressesare then associated with the gateway's northbound interface, and thecloud provider's gateway performs translation from these secondary IPaddresses to public IP addresses. In the centralized case, other networkservices may also be applied at the gateway, such as service chaining(sending packets out to third-party service appliances for variousmiddlebox processing), intrusion detection, north-south firewall, VPN,audit logging, etc. In addition, when the gateway performs NAT, any loadbalancing will need to be performed in the gateway as well (the cloudprovider may not be able to perform load balancing in this case becauseas far as the provider's gateway is concerned, all traffic is sent tothe gateway interface).

Other embodiments perform the first level of NAT in a distributedmanner, in the MFE operating on the source VM (destination VM forincoming traffic). In this case, for outgoing packets, the source MFEperforms address translation and sends the translated packet directly tothe cloud provider gateway, bypassing the gateway. As such, the sourceMFE differentiates between overlay traffic that it encapsulates usingits VTEP IP and north-south traffic that it sends unencapsulated ontothe cloud provider underlay network. Because this traffic (in bothdirections) does not pass through the gateway, any service chaining,intrusion detection, north-south firewall rules, logging, etc. isperformed at the MFE operating on the workload VM.

For load balancing, distributed internal NAT allows the use of existingload balancing features of the cloud provider. Instead of using multiplepublic IP addresses, a single address (or only a small number ofaddresses) can be used, and all incoming connections are sent to thisaddress. The internet gateway (or a special load balancing appliance) ofthe cloud provider performs load balancing to distribute theseconnections across different workload VMs (which still need to performtheir own internal NAT) in a balanced manner.

A. Centralized NAT

In the centralized NAT case, the MFEs operating in workload VMs areconfigured in the same overlay mode manner as shown above in SectionV.B. In either non-overlay mode or overlay mode with migrated IPaddresses, no internal layer of NAT is required, because the IP addresswith which packets are sent out will match that of the VM's networkinterface. However, for overlay mode, as mentioned, the internal layerof NAT is performed by the gateway datapath operating in the gateway VMwithin the VPC of the source (or destination, for incoming packets).

FIG. 21 conceptually illustrates an example of packet processing througha cloud provider network for a northbound packet sent from a workloadapplication to a destination outside the logical network (e.g., anInternet client, a destination on a completely separate logical network,etc.). FIG. 21 includes two host machines 2105 and 2110 operating VMs inthe same VPC in a public datacenter, as well as a public cloud gateway2115 that also operates in the same public datacenter, though not withinthe same VPC. A workload VM 2120 operates on the first host machine2120, with a workload application 2125 and a MFE 2130 (in overlay mode)executing in the workload VM. A gateway VM 2135 operates on the secondhost machine 2110, with a gateway datapath 2140 executing on the VM (inaddition to a controller, PCM, etc. that are not shown here). Asmentioned, the MFE 2130 operates in overlay mode, with an internal IPaddress A associated with the logical switch port to which the workloadattaches and a VTEP IP address associated with the VPC subnet of thecloud provider. In addition, each of the host machines 2105 and 2110includes a respective public cloud forwarding element 2145 and 2150 towhich their respective VMs connect. As in the previous cases, thesepublic cloud forwarding elements may be software virtual switches, towhich the network control system does not have access. The public cloudgateway 2115 may operate as a separate physical appliance, a VM, or anyother form factor. This gateway 2115 handles non-VPN traffic betweenVPCs located in the public datacenter and machines outside the publicdatacenter.

As shown, the workload application 2125 sends a packet 2145 to the MFE2130 on its VM 2120. As with the packets in previous examples, thispacket 2145 contains source and destination IP addresses (and MACaddresses), various headers, and a payload. The source IP address A isthe internal IP address of the workload application 2125 (as opposed tothe VM interface IP address), while the destination IP address Q is thatof a destination external to the logical network.

At this point, the MFE 2130 performs logical switch and logical routerprocessing (assuming a single-tier logical router topology) anddetermines that the packet should be sent to the uplink port of thelogical router. This uplink port maps to the gateway datapath 2140, sothe MFE 2130 encapsulates the packet 2145 to be tunneled to thegateway's VTEP. The MFE 2130 outputs this encapsulated packet 2150 fromthe VM interface, which connects to the public cloud forwarding element2135. As shown, the source IP address for this encapsulation is that ofthe VTEP of the MFE (i.e., the address of the VM interface), while thedestination IP address is that of the VTEP of the gateway datapath 2140(i.e., the address of the gateway VM interface used for tunnel traffic).

Assuming the public cloud forwarding network uses tunneling between hostmachines, the public cloud forwarding element 2135 encapsulates thepacket 2150 a second time with its own underlay encapsulation and sendsthis twice-encapsulated packet 2155 out over the physical cloud providernetwork. The underlay encapsulation uses the IP addresses of interfacesof the host machines 2105 and 2110 as its source and destination IPaddresses, respectively.

After traveling through the underlay network, the packet 2155 isreceived by the host machine 2110, where the public cloud forwardingelement 2140 removes the underlay encapsulation. The forwarding element2140 sends the still-encapsulated packet 2150 to the gateway VM 2135 viathe gateway VM's interface for tunneled traffic, based on thedestination IP address of the overlay encapsulation. The gatewaydatapath 2140 processes this packet 1955 by removing the encapsulationand identifying that the destination IP address corresponds to itsuplink port.

The gateway datapath 2140 (e.g., the centralized routing component inthe datapath) then determines that network address translation isrequired for the packet, in order for the packet to be sent out of thelogical network to its destination Q. As such, the gateway datapath usesa NAT table to identify the IP address provided by the public cloudprovider to which to map the source address A. When the gateway 2140 isnot performing load balancing, some embodiments allocate one IP addressper workload application. For centralized NAT, some embodiments do notuse the VM interface IPs, because incoming packets should be directed tothe gateway 2140 rather than directly to the workload VMs from thepublic cloud gateway 2115. Instead, the tenant will have a number of“secondary” IP addresses allocated from the public cloud provider, allof which map to the uplink interface of the gateway datapath 2140. Inthis case, the gateway performs its NAT to modify the source IP addressof the packet 2145 from A to B1, while the destination IP addressremains Q.

The gateway outputs this translated packet 2160 to the public cloudforwarding element 2140, which subsequently encapsulates the packet 2160for the public cloud provider underlay tunnel, and sends theencapsulated packet 2165 through the cloud provider network to thepublic cloud gateway 2115. Here, the public cloud gateway 2115 performsits own NAT using a separate NAT table that maps the various secondaryIP addresses to public IP addresses (e.g., to elastic IPs that aredynamically allocable). In this case, the public cloud gateway's NATtable specifies to map the secondary IP address B1 to the public IPaddress C1. The public cloud gateway then sends this new translatedpacket 2170 onto an external network (e.g., the Internet) towards itsdestination Q.

FIG. 22 illustrates the processing within the public cloud gateway whenan incoming packet 2200 is sent from a source Q to one of the public IPaddresses (C1) associated with the tenant's VPC. In this figure, thepacket travels the opposite path of that shown in the previous FIG. 21.That is, the packet 2200 is received by the public cloud gateway 2115,which performs NAT on the destination address according to its NATtable. In some embodiments, this NAT table is static (e.g., a 1:1 staticmapping between secondary IPs and public IPs).

The public cloud gateway translates the destination IP address C1 to B1and outputs the translated packet onto the underlay, sending theencapsulated packet 2205 to the gateway VM 2135 that is associated withthe address B1. The public cloud forwarding element 2140 removes theunderlay encapsulation and sends this packet 2210 to the uplinkinterface of the gateway. The gateway datapath 2140 performs its owninternal NAT processing to translate the secondary IP address B1 intothe new destination address A. In addition, the gateway datapath 2140performs logical network processing to identify that the destinationaddress A maps to a logical switch port located at the MFE 2120, andthus encapsulates the translated packet using its own southboundinterface as the source IP and the VTEP IP address of the MFE 2120 asthe destination IP. This packet then follows the path of any intra-VPCpacket, being encapsulated again by the public cloud forwarding element2140 on the host machine 2110, decapsulated by the public cloudforwarding element 2135 on the host machine 2105, delivered to the MFE2120 which decapsulates the overlay encapsulation, performs any securityprocessing required, and delivers the packet to the workloadapplication.

FIG. 23 illustrates the packet processing through the cloud providernetwork of FIG. 21 for a packet sent from a different workloadapplication on the same VPC as the workload application 2125. Thisfigure includes the host machine 2110 with a gateway VM 2135 and thepublic cloud gateway 2115, as well as a host machine 2300 on which a VM2305 operates. A workload application 2310 and a MFE 2315 execute on theVM 2305. The workload application 2310 has an internal IP address Dassociated with the logical switch to which it attaches, while the VTEPof the MFE 2315 has a different IP address.

In this example, the workload application 2310 sends a packet 2320 withthe source address D. This packet follows a similar path as the packet2145 in FIG. 21, until it reaches the gateway datapath 2140. Thisdatapath 2140 identifies that source NAT is required for the packet2145, and therefore consults its internal NAT table to determine thatthe address D should be mapped to a secondary IP address B2, differentfrom that to which the IP address A maps. The gateway datapath sends thetranslated packet 2325 out its same uplink interface using a differentIP address than in the previous example. As a result, when thetranslated packet 2325 reaches the public cloud gateway 2115 with asource address B2, the public cloud gateway 2115 translates this sourceaddress to a different public IP address C2, and sends the packet 2330out to the external network.

The above figures assume that the cloud provider will allow multiple IPaddresses for a single interface of a VM. If the cloud provider does notenable this feature, then only one public IP address will be possibleusing centralized NAT. In this case, if only outbound connections areinitiated, multiple internal IP addresses may be used, and the NAT tablein the gateway uses stateful translation rules to assign return trafficthe correct destination IP address. For inbound connection origination,L4 port-based DNAT rules can be configured in the gateway to forwardtraffic to the correct applications/VMs, so long as the differentapplications run on different L4 ports.

B. Distributed NAT

In the distributed NAT case of some embodiments, the MFEs operating inthe workload DCNs are also configured in the same overlay mode manner asshown above, but these MFEs also perform NAT on north-south packets. Asa result, north-south traffic does not need to be sent to the gatewayoperating in the VPC. FIG. 24 conceptually illustrates a VM 2405 with amanaged forwarding element 2400 configured in overlay mode with distinctIP addresses, and which also performs NAT for north-south traffic. TheMFE 2400 is configured in a similar manner to the MFE 1700 shown in FIG.17, with the workload application 2410 connected to the integrationbridge 2415 via an internal interface having an inner IP address, andthe integration bridge having an overlay port through which packets aresent to a VTEP on the PIF bridge 2420. The VTEP has a separate IPaddress provided by the cloud provider, which is associated with aninterface of the VM.

The difference, in this case, is that a patch port also is configuredbetween the integration bridge 2415 and the PIF bridge 2420. Theintegration bridge performs logical processing on outgoing packets and,for east-west traffic (e.g., when the destination is identified ascorresponding to a logical port other than a logical router uplinkport), encapsulates the packets and sends them out of the overlay port.On the other hand, for north-south packets (that map to an uplink portof a logical router), the integration bridge 2415 instead performssource NAT on these packets and sends them directly to the PIF bridge2420 unencapsulated via the patch port (as was the case with traffic inthe non-overlay case). In some embodiments, the MFE also createsstateful rules to process return traffic for the connection; in otherembodiments, because only one mapping of a single internal IP address tocloud provider-assigned IP address is used for all connections, nostateful rules are required. The NAT address may be the same as the VTEPIP address in some embodiments, so that the tenant does not need to havethe cloud provider assign multiple IP addresses. In other embodiments,the two IP addresses are different, in which case the VM either hasmultiple interfaces or multiple IP addresses for the same interface.

For incoming traffic, the PIF bridge 2420 identifies whether the packetis tunnel traffic or southbound traffic from an external source. Someembodiments identify whether the packet has a destination IP address inthe limited set of IP addresses corresponding to the other VTEPs in theVPC, including the gateway, to classify incoming traffic as intra-VPCoverlay traffic. Overlay traffic is sent to the VTEP so that theintegration bridge 2415 will receive the traffic on the overlay port anddecapsulate the packets, while southbound traffic is sent to theintegration bridge 2415 via the patch port. For this southbound traffic,the integration bridge 2415 performs destination NAT either based onstored state (e.g., for return traffic, if state is stored) or using itsNAT rules (e.g., for newly initiated incoming connections or in if nostateful NAT rules are stored).

FIGS. 25 and 26 illustrate examples of packet processing through a cloudprovider network for northbound and southbound in the distributed NATsetup. Specifically, FIG. 25 illustrates an example of packet processingfor a northbound packet sent from a workload application to adestination outside the logical network (e.g., an Internet client, adestination on a completely separate logical network, etc.). FIG. 25includes only a single host machine 2505 that hosts a VM operating in aVPC. A workload VM 2510 operates on the host machine 2505, with aworkload application 2515 (having an internal IP address A) and a MFE2520 executing in the workload VM. As in the previous examples, the hostmachine 2505 also includes a public cloud forwarding element 2525, whichmay be a software virtual switch to which the network control systemdoes not have access. In addition, the figure shows a public cloudgateway 2530 that may operate as a separate physical appliance, VM, etc.to handle non-VPN traffic between VPCs located in the public datacenterand machines outside the datacenter.

As shown, the workload application 2515 sends a packet 2535 to the MFE2520 on its VM 2505. This packet has a source IP address A (the internalIP address of the workload application, associated with a logical switchport) and a destination IP address Q of a remote external destination.The MFE 2520 performs logical switch and router processing, and mapsthis destination address to an uplink logical router port. In this case,the MFE is configured to perform NAT for packets sent to this logicalport, and thus translates the source IP address from A to N according toits NAT configuration. As mentioned, the IP address N may be the same asthe VTEP address used for tunneling within the VPC, or it may be adifferent IP address also assigned by the cloud provider.

The MFE 2520 then sends this translated packet 2540 out to the publiccloud forwarding element 2525 without encapsulation. This packet isencapsulated by the forwarding element 2525 and sent on the underlay(public cloud) network directly to the public cloud gateway 2530,thereby skipping the VPC gateway that is required for north-southtraffic in the centralized NAT case. The public cloud gateway 2530 hasits own NAT table, and after removing the underlay encapsulationtranslates the source IP address from N to M, a public IP addressregistered to the tenant.

FIG. 26 illustrates the processing for a southbound packet sent to theworkload application 2515 from an external source with IP address Q viathe public cloud gateway 2530. In this figure, the public cloud gateway2530 receives a packet 2605 having a source IP address Q and adestination IP address M, which (as indicated above) is a public IPaddress associated with the workload VM 2510. This packet follows theopposite path of the packet described in FIG. 25. The public cloudgateway 2530 performs NAT to translate the destination IP address to theprivate IP address N, and forwards the packet (on the provider underlaynetwork) to the VM 2510. After the public cloud forwarding element 2525removes the underlay encapsulation, the MFE 2520 identifies that thepacket is a southbound, non-encapsulated packet, and performs logicalrouter and logical switch processing on the packet. As part of thelogical router processing, the MFE 2520 translates the destination IPaddress from N to A, the IP address of the workload application 2515.The MFE 2520 then delivers this packet to the workload application 2515.

FIG. 27 conceptually illustrates a process 2700 performed by a MFE on aworkload VM to process an outgoing packet, when the MFE operates inoverlay mode and is configured to perform distributed NAT. An example ofsuch a MFE is the MFE 2400 shown in FIG. 24. It should be understoodthat the process 2400 is a conceptual process, and the MFE (especially aflow-based MFE) may not make determinations as shown in the figure.Instead, such a MFE would process the packet through its flow tables andperform operations according to the matched flow entries. That is, theresult of the processing would dictate an action or set of actions totake, rather than the MFE evaluating a yes/no decision as to whether totake a particular action. However, the process 2700 is representative ofthe different operations that the MFE performs given different types ofpackets.

As shown, the process 2700 begins by receiving (at 2705) a packet from alocal workload application. As the MFE is operating in overlay mode,this packet will have the internal IP address as its source address(assuming the MFE has not been compromised). The process then performs(at 2710) logical network and security processing according to itsconfiguration (i.e., the configuration rules pushed down by its localcontrol agent). This may include logical switch and/or logical routerprocessing, distributed firewall processing, etc.

The process 2700 determines (at 2715) whether the destination for thepacket is in the same VPC as the VM on which the MFE operates. When thisis the case, the process encapsulates (at 2720) the packet, with thesource IP address for the encapsulation being the local VTEP IP addressand the destination IP address being the VTEP of the destination MFEwithin the VPC. An example of this processing is illustrated in FIG. 18,described above.

If the destination is not in the same VPC, the process 2700 determines(at 2725) whether the destination is an external destination (i.e.,whether the packet is a northbound packet). If this is not the case,then the packet is addressed to a logical port located in a differentVPC or datacenter, and the process encapsulates (at 2730) the packet,with the source IP address for the encapsulation being the local VTEP IPaddress and the destination IP address being the VTEP of the gatewaywithin the VPC. An example of such processing is illustrated in FIG. 19,also described above. In either of these situations, the MFE identifiesa logical switch port within the logical network (though not necessarilyon the same logical switch as the local workload application) as thedestination for the packet, and thus tunnels the packet to eitheranother local VM or the gateway (in the latter case, so that the gatewaycan send the packet towards its eventual destination).

However, if the destination is an external destination (e.g., if thedestination IP address maps to an uplink logical router port), theprocess performs (at 2735) NAT to change the source IP address from theinternal workload application IP address to an IP address assigned bythe cloud provider. This IP address may be the same as the local VTEP IPaddress, but in this case the address is used as the source IP addressfor the inner packet (without any encapsulation), rather than as thesource IP address in a GENEVE, STT, etc. tunnel header. An example ofthis processing is shown in FIG. 25. Lastly, the process sends (at 2740)the packet to the cloud provider forwarding element on its host machine,to be sent on the cloud provider's network.

Using distributed NAT, as shown here, enables seamless integration withexternal cloud provider services, such as storage services, in someembodiments. These external resources can easily determine from whichDCN on a VPC they are being accessed, and thus use identity-basedpolicies to control access to these resources. In the centralized NATcase, all such resources would be accessed via the gateway, using IPaddresses that do not correspond to the interfaces of the workload DCNs.In addition, the use of distributed NAT allows for easy integration withload balancing services offered by a number of cloud providers.

FIG. 28 illustrates the use of load balancing in a public cloud gateway2800 along with distributed NAT by MFEs operating in workload VMs. Thisfigure illustrates two public cloud host machines 2805 and 2810operating VMs within a VPC. Specifically, a first VM 2815 operates onthe first host machine 2805 and a second VM 2820 operates on the secondhost machine 2810. The first VM 2815 executes a workload application2825 with an internal IP address A, while the second VM 2820 executes aworkload application 2830 with an internal IP address B. In thisexample, the two workload applications are instances of the sameexternally-accessible application (e.g., multiple web server instances).In addition, MFEs 2835 and 2840 respectively execute on the two VMs 2815and 2820, and the host machines 2805 and 2810 respectively includepublic cloud forwarding elements 2845 and 2850.

The public cloud gateway 2800 (or a separate load balancing applianceprovided by the public cloud to attract southbound traffic for the VPC)receives two packets 2855 and 2860. Both of these packets have adestination IP address X (the public IP address associated with theworkload applications 2825 and 2830), but are from different sources Qand R. Thus, upon receipt by the public cloud gateway 2800, this gatewayperforms a load balancing and destination network address translationoperation to balance the traffic among these two workloads (and possiblyamong additional instances on additional VMs).

Based on various factors (a hash of the IP addresses and/or otherheaders, monitoring of the current traffic load on the differentworkloads, etc.), the public cloud gateway 2800 selects the destinationIP address Y for the first packet 2855, and the destination IP address Zfor the second packet 2860. These two IPs correspond to cloud providerassigned VM interfaces of the VMs 2815 and 2820 respectively, and thusthe gateway tunnels the packets to the two host machines 2805 and 2810.Assuming these were the first packets in a connection, the gateway alsostores the connection and NAT mapping so that any ongoing traffic forthe connection will be sent to the same workload application (if theywere not the first packets, the gateway would process the packetsaccording to previously-stored state in some embodiments).

When the MFEs 2835 and 2840 receive the packets, they recognize thetraffic as unencapsulated southbound traffic, and therefore performtheir own NAT on the packets. These NAT operations translate thedestination IP address Y to A for the first packet at the first MFE 2835and translate the destination IP address Z to B for the second packet atthe second MFE 2840.

This use of load balancing also enables auto-scaling of new workloadVMs, if supported by the cloud provider. With auto-scaling, if theworkloads are too heavily taxed, the cloud provider automaticallycreates a new instance running the same application, and the provider'sload balancer begins taking the new instance into account in its loadbalancing decisions.

VII. Distributed Network Encryption

Some embodiments enable the use of distributed network encryption (DNE),managed by the network control system, within the public datacenter. Insome embodiments, DNE is only available between DCNs operating withinthe same VPC or within peered VPCs, while in other embodiments DNE isavailable between any two DCNs attached to logical ports of the logicalnetwork (including between a workload DCN and a gateway).

Distributed network encryption, in some embodiments, allows the networkcontrol system administrator to set encryption and/or integrity rulesfor packets. These rules define (i) to which packets the rule will beapplied and (ii) the encryption and/or integrity requirements for thosepackets. Some embodiments define the packets to which a rule applies interm of the source and destination of the packet. These source anddestination endpoints may be defined based on IP addresses or addressranges, MAC addresses, logical switch ports, virtual interfaces, L4 portnumbers and ranges, etc., including combinations thereof.

Each rule, in addition, specifies whether packets meeting the source anddestination characteristics require encryption (possibly along withauthentication), only authentication, or plaintext (which may be used asa setting in order to allow broadcast packets). Encryption requires theuse of a key to encrypt a portion or all of a packet (e.g., the entireinner packet, only the L4 and up headers, the entire inner and outpacket for a tunneled packet, etc.), while authentication does notencrypt the packet but uses the key to generate authentication data thatthe destination can use to verify that the packet was not tampered withduring transmission (e.g. a hash of the packet or a portion thereof).

To have the MFEs in a network implement the DNE rules, the networkcontrol system needs to distribute the keys to the MFEs in a securemanner. Some embodiments use a DNE module in the gateway VMs in order tocommunicate with the DNE aspects of the network control system anddistribute keys to the MFEs operating in the workload VMs in its VPC.FIG. 29 conceptually illustrates such a DNE rule and key distributionsystem 2900 of some embodiments, as well as the flow of data toimplement a DNE rule on a MFE in the public datacenter.

The DNE rule/key distribution system 2900 includes management plane2905, central control plane 2910, and key manager 2915 within theprivate datacenter. These components could also be located in a separateVPC (or the same VPC) of a public datacenter, but in general networkadministrators will want to keep these components on their own privatedatacenter, as the key manager 2915 securely stores the master keys foruse in the DNE system. While a brief description of the operations ofthese components is given here, the ticket and key distributionprocesses are described in greater detail in U.S. Provisional PatentApplication 62/380,338, which is incorporated by reference above.

The management plane 2905 and central control plane 2910 have beendescribed above, in relation to their operations in distributing networkforwarding and security rules. As with forwarding configuration, whenthe management plane 2905 receives a DNE rule (e.g., from a cloudmanagement platform configured with the management plane APIs), itformats this rule and passes the rule to the central control plane 2910.The central control plane 2910 performs a span computation for the rulein order to identify the local controllers, including any gatewaycontrollers in public datacenter VPC, that require the rule.

The key manager 2915 of some embodiments is a secure storage that storesencryption keys for use by the MFEs managed by the network controlsystem 2900. In some embodiments, the key manager 2915 is a hardwareappliance, a VM operating in a secure manner in the private datacenter,etc. In some embodiments, the key manager specifies constructs andmechanisms to define groups of keys for manageability, and providesvarious security controls (e.g., access control and authentication) toaccess keys. In some embodiments, the authentication mechanisms includepublic key infrastructure (PKI) certificates, user credentials, and/orshared secrets. The key manager of some embodiments also enforcesattestation of the requester to address the malicious requester threats.

The key manager 2915 registers with the management plane 2905, andobtains certificates for the management plane 2905, central controlplane 2910 (i.e., one or more controllers in the central control planecluster), and local controllers (including any gateway controllers). Byhaving the key manager 2915 obtain these certificates upon registration,the network control system 2900 avoids duplicative communication at thetime a local controller requires a key for a specific DNE rule (i.e.,communication to verify that the local controller requesting a key is avalid controller).

In some embodiments, the key manager 2915 generates keys based on keyrequests, in addition to storing keys that have been generated based onsuch requests. The stored keys may be used if subsequent requests forthe same key are required (e.g., if a VM that requires a key is poweredoff and back on, or otherwise restarts). Some embodiments store the keysin the key manager 2915 encrypted with a key encryption key, which issecured in a password protected read-only file and loaded in to thememory of key manager 2915 during an initial stage with input from ahuman administrator.

Within the public datacenter VPC, the system 2900 includes a gateway VM2920 with a gateway controller 2925 and a DNE module 2930, as well as aworkload VM 2935. The gateway VM 2920 and its gateway controller 2925are described in detail above, and it should be understood that thegateway VM 2920 may also execute various other features, such as thegateway datapath, public cloud manager, etc. that are described above inSection II.

The DNE module 2930 is responsible for handling any keys needed by anyof the MFEs within the VPC of the gateway VM 2920. The DNE module 2930interacts with the key manager 2915 in order to manage encryption keysfor the MFEs in its VPC. When the central control plane 2910 receivesrules specifying encryption and/or authentication requirements forpackets sent to or from any of the workloads operating in the VPC, thecentral controller distributes these rules to the gateway controller2935). The encryption rules of some embodiments include a ticket used bya controller to acquire a key from the key manager 2915. The DNE module2930, or the gateway controller 2925, uses this ticket to request a keyfrom the key manager 2915, which provides a master key for theencryption rule. The DNE module 2930 receives the master key and usesthis key to generate a session key for the rule. The session key, insome embodiments, is generated as a function of the master key and oneor more additional parameters specific to the two endpoints that will beperforming encryption. The DNE module 2930 (e.g., via the gatewaycontroller 2925) distributes the generated session keys to theappropriate endpoints.

The workload VM 2935 is one of several workload VMs operating in thesame VPC of the public datacenter. The VM includes a local control agent2940, as well as the MFE that actually implements DNE rules, a workloadapplication, etc. (which are not shown).

Having described the operation of the components of the system 2900, theexample data flow shown in FIG. 29 will now be described. As shown bythe encircled 1A, the management plane 2905 passes a DNE rule 2950 tothe central control plane 2915. This DNE rule 2950 would have beenreceived as input (e.g., from a network administrator, possibly via acloud management interface) through APIs of the management plane. TheDNE rule 2950, as described above, specifies to which packets the ruleapplies and (ii) the encryption and/or integrity requirements for thosepackets. In some embodiments, the rule might also include policies suchas the type of encryption to use, how often to rotate (i.e., modify in aspecific manner) the key in use, whether to revoke the key after aspecific amount of time, etc.

The central control plane 2910 receives this rule 2950 and determinesits span. If the rule has specific source and destination endpoints,then the span might be only the two first-hop MFEs for those endpoints.On the other hand, a rule might specify for all traffic to or from aspecific logical port to be encrypted, in which case the first-hop MFEsfor all endpoints that might be communicating with the specific logicalport will need to receive the rule. In this example, at least theapplication operating on the VM 2935 is an endpoint for the rule, andthus the central control plane determines that the span for the ruleincludes the gateway controller 2925. As shown by the encircled 1B, thecentral control plane 2910 distributes this DNE rule 2950 to the gatewaycontroller 2925. The gateway controller 2925 determines the span of therule within its VPC, identifies the MFE on the workload VM 2935 as oneMFE that requires the rule (for intra-VPC encryption, at least oneadditional endpoint will need the rule, and for encryption outside theVPC, the datapath on the gateway VM will need the rule), and distributesthe rule 2950 to the local control agent 2940 on the VM 2935, as shownby the encircled 1C.

In addition to the rule itself, in some embodiments the CCP distributesa ticket 2955 to the gateway controller 2925, as shown by the encircled2. In some embodiments, an encryption key ticket is generated for thegateway controller based on a key identifier and a security parameterindex (SPI). The security parameter index, in some embodiments,identifies the security properties of a connection (e.g., between twoendpoints) for which DNE will be used, such as the key length,encryption algorithm, etc. This ticket 2955 acts as a security token forretrieving a key from the key manager 2915. In some embodiments, theticket includes a key identifier, a local controller identifier, anexpiration time, and a signature.

Upon receiving the ticket 2955, the gateway controller passes the ticket(not shown) to the DNE module 2930, which sends a key request 2960 tothe key manager 2915, as shown by the encircled 3. In some embodiments,the gateway controller 2925 actually sends the key request to the keymanager itself. The request includes the ticket or information from theticket certifying that the gateway controller is authorized to receivethe key by the central control plane. The key manager 2915 verifies thisrequest, and sends a master key 2965 to the gateway VM 2920, as shown bythe encircled 4. In this figure, the DNE module 2930 receives thismaster key 2965. In some embodiments, the master key 2965 is sent to thegateway controller 2925, which passes the key to the DNE module 2930.

The DNE module 2930 uses the master key to generate a session key forthe MFE at the VM 2935 (and at any other VMs that will use the key). Insome embodiments, the session key is a function of the master key, SPIsrelating to the two endpoints of the connection and/or VTEP IP addressesof the two endpoints, and a random number. In some embodiments, if therule specifies multiple connections (e.g., from source A to eitherdestination B or destination C), then the DNE module 2930 generatesdifferent session keys for each connection between two endpoints. Thatis, in the above example, two session keys are generated, one for theconnection between A and B and one for the connection between A and C.Some embodiments use symmetric key encryption, in which case the samesession key is distributed to each endpoint of a connection. As shown bythe encircled 5, the DNE module 2930 (either directly or through thegateway controller) distributes a session key 2970 to the local controlagent 2940.

In some embodiments, the encryption on the agent is not performed by theMFE itself (i.e., by the integration bridge or PIF bridge). Instead, aDNE module operating on the workload VM integrates with the networkstack (i.e., the network stack between the integration bridge and PIFbridge, for the IP address of the VM interface). The IPsec functionalityof the network stack uses the appropriate session key to encrypt and/orgenerate integrity information for outgoing packets and decrypt and/orauthenticate incoming packets. The flow entries in the MFE indicatewhether or not encryption/decryption and/or authentication need to beperformed for a given packet.

FIG. 30 conceptually illustrates a process 3000 of some embodiments formanaging DNE keys in the gateway of a public datacenter VPC. The process3000 is performed, in some embodiments, by a gateway VM in the VPC(e.g., by the gateway controller and/or DNE module of the gateway VM. Insome embodiments, the gateway VM performs this process or a similarprocess for each DNE rule it receives.

As shown, the process 3000 begins by receiving (at 3005) a rule from acentral controller specifying a DNE rule for at least one logical portin the VPC. As described above, the central controller views the gatewaycontroller as the local controller for all of the workloads operating inits VPC. The DNE rule might pertain to a connection between twoendpoints in the VPC, multiple connections between multiple endpoints inthe VPC, a connection between an endpoint in the VPC and a logicalnetwork endpoint located elsewhere, a connection between the gatewaydatapath and another endpoint in the VPC, or combinations thereof. TheDNE rule of some embodiments requires encryption and/or authenticationof packets between the endpoints of the specified connection as well.

In addition, the process 3000 receives (at 3010) from the centralcontroller a ticket for a key to use in the encryption and/orauthentication process. This ticket, in some embodiments, is generatedby the central controller based on a key identifier and/or SPI. Theticket acts as a security token for retrieving a key from the keymanager of the network encryption system. In some embodiments, theticket includes a key identifier, a local controller identifier, anexpiration time, and a signature.

Next, the process sends (at 3015) a request for the key to the keymanager, using the ticket. Some embodiments send the ticket itself,while other embodiments send data derived from the ticket. The keymanager uses the ticket or other information in the request to identifythe required key and verify that the gateway controller is authorized toreceive the key.

Assuming the key manager verifies the request, the process receives (at3020) a master key from the key manager. The master key is generated bythe key manager at the time of the request. The process then calculates(at 3025) one or more session keys based on the received master key. Ifthe rule specifies multiple possible connections governed by a rule,some embodiments generate different session keys from the master key foreach such connection. Some embodiments calculate the session key as afunction of the master key, features about the two endpoints of thespecific connection (e.g., VTEP labels, VTEP IP addresses, SPIspertaining to the endpoints, etc.), and/or a randomly generated number.

The process then sends (at 3030) the session key(s) to the local controlagents for any MFEs that require the key(s) (i.e., the agents for theMFEs at either end of each connection). This may include also sendingthe keys to the gateway datapath if necessary. In addition, in someembodiments, the DNE module on the gateway securely stores the keys sothat they can be re-distributed if a workload VM or its agent isrestarted and the agent requires the previously-distributed information.

VIII. Threat Detection

Especially with DCN workloads operating in the public cloud, and withthe MFEs operating on those DCNs, security can be a concern. If a hackergained root access to a DCN, he or she might be able to bypass theenforcement of network security policies (and thereby send traffic incontradiction to those policies) because the security policies areenforced by the MFE operating in the DCN itself, rather than in thevirtualization software of the machine on which the DCN operates.

A hacker (or other rogue user) on a compromised DCN might bypass networksecurity policies in one of several different ways. For instance, theuser could (i) remove (e.g., uninstall) the local control agent, (ii)disconnect the network interface from the MFE and run the network stackdirectly on the interface, so as to bypass the security policyenforcement, or (iii) modify the configuration so that the local controlagent is not the controller of the MFE (e.g., of the integration bridgethat enforces security policies), thereby directly configuring the MFE(e.g., installing new flow entries).

However, gateway controller of some embodiments enables the networkcontrol system to handle these situations by identifying the compromisedDCN, and ensuring that the public cloud forwarding element to which theDCN connects (e.g., a virtual switch in the host machine) will preventthe compromised DCN from sending data traffic. The local control agenton the compromised DCN can detect the second and third situations listedabove, and notify the gateway controller. If the agent is removed, thegateway controller will notice the non-existence of its connectivity tothis controller.

FIGS. 31 and 32 illustrate examples of a gateway controller 3130identifying compromised VMs in its public datacenter VPC, so that thecompromised VM can be quarantined. Specifically, FIG. 31 illustrates thecase in which an agent is uninstalled, over two stages 3105-3110. Asshown in the first stage, a gateway VM 3100 includes the gatewaycontroller 3130 (in addition to its other components), and a VM 3135 inthe VPC executes an agent 3140 (in addition to a workload applicationand the MFE controlled by the agent). In the first stage 3105, aconnection exists between the gateway controller 3130 and the agent3140.

However, at this first stage 3105, the VM is compromised and the userlogged into the VM deletes (e.g., uninstalls) the agent 3140, so thatthe MFE on the VM cannot receive security policies. As shown at thesecond stage 3110, this removes the connection between the agent and thegateway controller 3130, so that the gateway controller detects that theagent is no longer operating. It should be noted that this could occurif the agent restarted or otherwise went down without the VM beingcompromised, but that some embodiments quarantine the VM anyway in thesecases until the agent is back up.

While this example shows the agent being completely uninstalled, asimilar loss of connection would occur if the hacker simply modified theconfiguration of the agent to receive its configuration rules from adifferent controller (i.e., one controller by the hacker). Because theagent would no longer be configured to receive configuration from thegateway controller, the agent would break communication with the gatewaycontroller, appearing to the gateway controller as though the agent hadbeen removed.

FIG. 32 illustrates the case in which an attacker creates a newinterface on a compromised VM 3200, over two stages 3205-3210. The VM3200 has an agent 3225 executing on it, and operates in the same VPC asthe gateway VM 3100. In the first stage 3205, a new interface has beencreated on the VM 3200, and this interface is being used to sendnon-secure data. The interface is not connected to the MFE, andtherefore applications on the VM are able to send packet directlythrough a network stack to the interface without any sort of securityprocessing.

However, in the second stage 3210, the agent detects the presence of thenew interface and reports this interface to the gateway controller 3130.In some embodiments, the new interface will automatically be populatedin a database (e.g., an OVSDB database) managed by the agent, and thusthe agent detects this change. Because the interface is not connected tothe MFE, the agent reports this interface to the gateway controller asan untrusted interface. Similarly, the agent would notify the gatewaycontroller if the existing interface was changed so that it receivedpackets directly from the workload application without the intermediaryprocessing of the MFE.

IX. Electronic System

Many of the above-described features and applications are implemented assoftware processes that are specified as a set of instructions recordedon a computer readable storage medium (also referred to as computerreadable medium). When these instructions are executed by one or moreprocessing unit(s) (e.g., one or more processors, cores of processors,or other processing units), they cause the processing unit(s) to performthe actions indicated in the instructions. Examples of computer readablemedia include, but are not limited to, CD-ROMs, flash drives, RAM chips,hard drives, EPROMs, etc. The computer readable media does not includecarrier waves and electronic signals passing wirelessly or over wiredconnections.

In this specification, the term “software” is meant to include firmwareresiding in read-only memory or applications stored in magnetic storage,which can be read into memory for processing by a processor. Also, insome embodiments, multiple software inventions can be implemented assub-parts of a larger program while remaining distinct softwareinventions. In some embodiments, multiple software inventions can alsobe implemented as separate programs. Finally, any combination ofseparate programs that together implement a software invention describedhere is within the scope of the invention. In some embodiments, thesoftware programs, when installed to operate on one or more electronicsystems, define one or more specific machine implementations thatexecute and perform the operations of the software programs.

FIG. 33 conceptually illustrates an electronic system 3300 with whichsome embodiments of the invention are implemented. The electronic system3300 can be used to execute any of the control, virtualization, oroperating system applications described above. The electronic system3300 may be a computer (e.g., a desktop computer, personal computer,tablet computer, server computer, mainframe, a blade computer etc.),phone, PDA, or any other sort of electronic device. Such an electronicsystem includes various types of computer readable media and interfacesfor various other types of computer readable media. Electronic system3300 includes a bus 3305, processing unit(s) 3310, a system memory 3325,a read-only memory 3330, a permanent storage device 3335, input devices3340, and output devices 3345.

The bus 3305 collectively represents all system, peripheral, and chipsetbuses that communicatively connect the numerous internal devices of theelectronic system 3300. For instance, the bus 3305 communicativelyconnects the processing unit(s) 3310 with the read-only memory 3330, thesystem memory 3325, and the permanent storage device 3335.

From these various memory units, the processing unit(s) 3310 retrieveinstructions to execute and data to process in order to execute theprocesses of the invention. The processing unit(s) may be a singleprocessor or a multi-core processor in different embodiments.

The read-only-memory (ROM) 3330 stores static data and instructions thatare needed by the processing unit(s) 3310 and other modules of theelectronic system. The permanent storage device 3335, on the other hand,is a read-and-write memory device. This device is a non-volatile memoryunit that stores instructions and data even when the electronic system3300 is off. Some embodiments of the invention use a mass-storage device(such as a magnetic or optical disk and its corresponding disk drive) asthe permanent storage device 3335.

Other embodiments use a removable storage device (such as a floppy disk,flash drive, etc.) as the permanent storage device. Like the permanentstorage device 3335, the system memory 3325 is a read-and-write memorydevice. However, unlike storage device 3335, the system memory is avolatile read-and-write memory, such a random access memory. The systemmemory stores some of the instructions and data that the processor needsat runtime. In some embodiments, the invention's processes are stored inthe system memory 3325, the permanent storage device 3335, and/or theread-only memory 3330. From these various memory units, the processingunit(s) 3310 retrieve instructions to execute and data to process inorder to execute the processes of some embodiments.

The bus 3305 also connects to the input and output devices 3340 and3345. The input devices enable the user to communicate information andselect commands to the electronic system. The input devices 3340 includealphanumeric keyboards and pointing devices (also called “cursor controldevices”). The output devices 3345 display images generated by theelectronic system. The output devices include printers and displaydevices, such as cathode ray tubes (CRT) or liquid crystal displays(LCD). Some embodiments include devices such as a touchscreen thatfunction as both input and output devices.

Finally, as shown in FIG. 33, bus 3305 also couples electronic system3300 to a network 3365 through a network adapter (not shown). In thismanner, the computer can be a part of a network of computers (such as alocal area network (“LAN”), a wide area network (“WAN”), or an Intranet,or a network of networks, such as the Internet. Any or all components ofelectronic system 3300 may be used in conjunction with the invention.

Some embodiments include electronic components, such as microprocessors,storage and memory that store computer program instructions in amachine-readable or computer-readable medium (alternatively referred toas computer-readable storage media, machine-readable media, ormachine-readable storage media). Some examples of such computer-readablemedia include RAM, ROM, read-only compact discs (CD-ROM), recordablecompact discs (CD-R), rewritable compact discs (CD-RW), read-onlydigital versatile discs (e.g., DVD-ROM, dual-layer DVD-ROM), a varietyof recordable/rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.),flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.),magnetic and/or solid state hard drives, read-only and recordableBlu-Ray® discs, ultra density optical discs, any other optical ormagnetic media, and floppy disks. The computer-readable media may storea computer program that is executable by at least one processing unitand includes sets of instructions for performing various operations.Examples of computer programs or computer code include machine code,such as is produced by a compiler, and files including higher-level codethat are executed by a computer, an electronic component, or amicroprocessor using an interpreter.

While the above discussion primarily refers to microprocessor ormulti-core processors that execute software, some embodiments areperformed by one or more integrated circuits, such as applicationspecific integrated circuits (ASICs) or field programmable gate arrays(FPGAs). In some embodiments, such integrated circuits executeinstructions that are stored on the circuit itself.

As used in this specification, the terms “computer”, “server”,“processor”, and “memory” all refer to electronic or other technologicaldevices. These terms exclude people or groups of people. For thepurposes of the specification, the terms display or displaying meansdisplaying on an electronic device. As used in this specification, theterms “computer readable medium,” “computer readable media,” and“machine readable medium” are entirely restricted to tangible, physicalobjects that store information in a form that is readable by a computer.These terms exclude any wireless signals, wired download signals, andany other ephemeral signals.

This specification refers throughout to computational and networkenvironments that include virtual machines (VMs). However, virtualmachines are merely one example of data compute nodes (DNCs) or datacompute end nodes, also referred to as addressable nodes. DCNs mayinclude non-virtualized physical hosts, virtual machines, containersthat run on top of a host operating system without the need for ahypervisor or separate operating system, and hypervisor kernel networkinterface modules.

VMs, in some embodiments, operate with their own guest operating systemson a host using resources of the host virtualized by virtualizationsoftware (e.g., a hypervisor, virtual machine monitor, etc.). The tenant(i.e., the owner of the VM) can choose which applications to operate ontop of the guest operating system. Some containers, on the other hand,are constructs that run on top of a host operating system without theneed for a hypervisor or separate guest operating system. In someembodiments, the host operating system isolates the containers fordifferent tenants and therefore provides operating-system levelsegregation of the different groups of applications that operate withindifferent containers. This segregation is akin to the VM segregationthat is offered in hypervisor-virtualized environments, and thus can beviewed as a form of virtualization that isolates different groups ofapplications that operate in different containers. Such containers aremore lightweight than VMs.

Hypervisor kernel network interface modules, in some embodiments, is anon-VM DCN that includes a network stack with a hypervisor kernelnetwork interface and receive/transmit threads. One example of ahypervisor kernel network interface module is the vmknic module that ispart of the ESX hypervisor of VMware Inc.

One of ordinary skill in the art will recognize that while thespecification refers to VMs, the examples given could be any type ofDCNs, including physical hosts, VMs, non-VM containers, and hypervisorkernel network interface modules. In fact, the example networks couldinclude combinations of different types of DCNs in some embodiments.

While the invention has been described with reference to numerousspecific details, one of ordinary skill in the art will recognize thatthe invention can be embodied in other specific forms without departingfrom the spirit of the invention. In addition, a number of the figures(including FIGS. 3, 4, 8-10, 27, and 30) conceptually illustrateprocesses. The specific operations of these processes may not beperformed in the exact order shown and described. The specificoperations may not be performed in one continuous series of operations,and different specific operations may be performed in differentembodiments. Furthermore, the process could be implemented using severalsub-processes, or as part of a larger macro process. Thus, one ofordinary skill in the art would understand that the invention is not tobe limited by the foregoing illustrative details, but rather is to bedefined by the appended claims.

We claim:
 1. For a network controller that configures forwardingelements (FEs) executing in at least a public first datacenter and asecond datacenter, the public first datacenter comprising a plurality ofhost computers executing a first set of FEs to which the networkcontroller does not have access, a method comprising: configuring afirst data compute node (DCN), that executes on a particular hostcomputer in the public first datacenter, to operate as a gateway FE fora logical overlay network between (i) a second set of FEs executing on afirst set of DCNs in the public first datacenter and (ii) a third set ofFEs executing in the second datacenter; configuring the second set ofFEs to implement a logical switch of the logical overlay network towhich the first set of DCNs attach, wherein (i) the first set of DCNsexecute on a set of host computers in the public first datacenter, (ii)the second set of FEs execute within the first set of DCNs, and (iii)the first set of FEs execute on the set of host computers and areoutside of the first set of DCNs executing on the set of host computers;and configuring the third set of FEs in the second datacenter toimplement the logical switch, wherein a second set of DCNs executing inthe second datacenter also attach to the logical switch such that thelogical overlay network provides a connection between the first set ofDCNs in the public first datacenter and the second set of DCNs executingin the second datacenter, wherein a first application executing on asecond DCN in the first set of DCNs communicates with a secondapplication executing on a third DCN in the second set of DCNs bysending a logical overlay network packet to a second-set FE executing inthe second DCN, the second-set FE sending the logical overlay networkpacket to the first DCN operating as the gateway FE via a first-set FEto which the second DCN connects, and the gateway FE sending the logicaloverlay network packet to the second datacenter.
 2. The method of claim1, wherein (i) the second datacenter is a public second datacenter and(ii) the network controller does not have access to a fourth set of FEsin the public second datacenter.
 3. The method of claim 2, wherein thenetwork controller operates in a private third datacenter.
 4. The methodof claim 1, wherein the first set of FEs to which the network controllerdoes not have access are managed by an administrator of the public firstdatacenter.
 5. The method of claim 4, wherein the first DCN and thefirst set of DCNs attach to the first set of FEs managed by theadministrator of the public first datacenter, wherein workloadapplications execute on the first set of DCNs and attach to the secondset of FEs executing on the first set of DCNs, wherein the firstapplication is one of the workload applications.
 6. The method of claim4, wherein (i) the second datacenter is a private datacenter and (ii)the third set of FEs are configured by the network controller andexecute outside of the second set of DCNs executing in the privatesecond datacenter that attach to the logical switch.
 7. The method ofclaim 6, wherein the network controller operates in the private seconddatacenter.
 8. The method of claim 1, wherein configuring the first DCNcomprises distributing a first set of configuration data to the firstDCN.
 9. The method of claim 8, wherein configuring the second set of FEsexecuting within the first set of DCNs comprises distributing a secondset of configuration data to the first DCN, wherein the first DCNdistributes different subsets of the second set of configuration data todifferent DCNs of the first set of DCNs.
 10. The method of claim 1,wherein the gateway FE sends the logical overlay network packet to thesecond datacenter by tunneling the logical overlay network packet to athird-set FE executing in the third DCN.
 11. The method of claim 1,wherein the first-set FE executing in the second DCN tunnels the logicaloverlay network packet to the gateway FE executing in the first DCN,wherein the gateway FE sends the logical overlay network packet to thethird DCN.
 12. The method of claim 11, wherein the gateway FE uses avirtual private network (VPN) between the public first datacenter andthe second datacenter to send the logical overlay network packet to thethird DCN.
 13. The method of claim 11, wherein the gateway FE sends thelogical overlay network packet to the third DCN by sending the logicaloverlay network packet to a fourth DCN configured to operate as a secondgateway FE in the second datacenter, wherein the second gateway FEtunnels the logical overlay network packet to a third-set FE executingin the third DCN.
 14. A non-transitory machine readable medium storing anetwork controller which when executed by at least one processing unitconfigures forwarding elements (FEs) executing in at least a publicfirst datacenter and a second datacenter, the public first datacentercomprising a plurality of host computers executing a first set of FEs towhich the network controller does not have access, the networkcontroller comprising sets of instructions for: configuring a first datacompute node (DCN), that executes on a particular host computer in thepublic first datacenter, to operate as a gateway FE for a logicaloverlay network between (i) a second set of FEs executing on a first setof DCNs in the public first datacenter and (ii) a third set of FEsexecuting in the second datacenter; configuring the second set of FEs toimplement a logical switch of the logical overlay network to which thefirst set of DCNs attach, wherein (i) the first set of DCNs execute on aset of host computers in the public first datacenter, (ii) the secondset of FEs execute within the first set of DCNs, and (iii) the first setof FEs execute on the set of host computers and are outside of the firstset of DCNs executing on the set of host computers; and configuring thethird set of FEs in the second datacenter to implement the logicalswitch, wherein a second set of DCNs executing in the second datacenteralso attach to the logical switch such that the logical overlay networkprovides a connection between the first set of DCNs in the firstdatacenter and the second set of DCNs executing in the seconddatacenter, wherein a first application executing on a second DCN in thefirst set of DCNs communicates with a second application executing on athird DCN in the second set of DCNs by sending a logical overlay networkpacket to a second-set FE executing in the second DCN, the second-set FEsending the logical overlay network packet to the first DCN operating asthe gateway FE via a first-set FE to which the second DCN connects, andthe gateway FE sending the logical overlay network packet to the seconddatacenter.
 15. The non-transitory machine readable medium of claim 14,wherein (i) the second datacenter is a public second datacenter and (ii)the network controller does not have access to a fourth set of FEs inthe public second datacenter.
 16. The non-transitory machine readablemedium of claim 15, wherein the network controller operates in a privatethird datacenter.
 17. The non-transitory machine readable medium ofclaim 14, wherein the first set of FEs to which the network controllerdoes not have access are managed by an administrator of the public firstdatacenter.
 18. The non-transitory machine readable medium of claim 17,wherein the first DCN and the first set of DCNs attach to the first setof FEs managed by the administrator of the public first datacenter,wherein workload applications execute on the first set of DCNs andattach to the second set of FEs executing on the first set of DCNs,wherein the first application is one of the workload applications. 19.The non-transitory machine readable medium of claim 17, wherein (i) thesecond datacenter is a private datacenter and (ii) the third set of FEsare configured by the network controller and execute outside of thesecond set of DCNs executing in the second datacenter that attach to thelogical switch, wherein the network controller operates in the privatesecond datacenter.
 20. The non-transitory machine readable medium ofclaim 14, wherein: the set of instructions for configuring the first DCNcomprises a set of instructions for distributing a first set ofconfiguration data to the first DCN; the set of instructions forconfiguring the second set of FEs executing within the first set of DCNscomprises a set of instructions for distributing a second set ofconfiguration data to the first DCN; and the first DCN distributesdifferent subsets of the second set of configuration data to differentDCNs of the first set of DCNs.
 21. The non-transitory machine readablemedium of claim 14, wherein the gateway FE sends the logical overlaynetwork packet to the second datacenter by tunneling the logical overlaynetwork packet to a third-set FE executing in the third DCN.
 22. Thenon-transitory machine readable medium of claim 14, wherein thefirst-set FE executing in the second DCN tunnels the logical overlaynetwork packet to the gateway FE executing in the first DCN, wherein thegateway FE sends the logical overlay network packet to the third DCN.23. The non-transitory machine readable medium of claim 22, wherein thegateway FE uses a virtual private network (VPN) between the public firstdatacenter and the second datacenter to send the logical overlay networkpacket to the third DCN.
 24. The non-transitory machine readable mediumof claim 22, wherein the gateway FE sends the logical overlay networkpacket to the third DCN by sending the logical overlay network packet toa fourth DCN configured to operate as a second gateway FE in the seconddatacenter, wherein the second gateway FE tunnels the logical overlaynetwork packet to a third-set FE executing in the third DCN.